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PREFACE 
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SECTION  1.  INTRODUCTION 


A  general  aim  of  the  Software  Acquisition  ’'Management  (SAM)  guidebook  series 
is  to  help  promote  more  effective  acquisition  of  software  elements  in  military 
systems.  Most  of  the  guidebooks  published  to  date  in  the  series  have  been 
devoted  to  selected  aspects  of  software  development  and  sunnort,  as  such,  in 
relation  to  management  concepts  which  apply  in  the  context  of  system  acquisition 
programs.  That  general  focus  is  significant,  since  a  working  knowledge  of  those 
special  concepts  and  nrocedures  is  critical  to  the  successful  acauisition  of 
software/computer  resources  in  that  context. 

This  guidebook  differs  from  others  of  the  series  in  that  its  tonic  relates 
somewhat  more  directly  to  the  system  as  a  whole  than  to  a  system's  software 
elements.  However,  integration  of  software  with  systems  is  a  two-way  nrocess. 
While  most  of  the  effort  may  be  pointed  properly  towards  adanting  "software 
management"  to  the  system  program  environment,  there  is  a  growing  recognition 
that  the  prominence  of  software- -particularly  in  ground  electronic  systems -- 
also  has  implications  for  management  at  the  system  level.  The  system  specifica¬ 
tion  (the  Tyne  A  specification  as  defined  in  MIL-S-83490)  was  chosen  as  the 
topic  of  this  guidebook  largely  because  it  is  the  designated  source  of  basic 
reauirements  for  the  system  software  functions  and  performance,  and  because 
many  of  the  problems  associated  wuth  software  acquisition  in  systems  have  been 
traceable  to  inadequacies  in  those  basic  requirements. 

The  material  contained  in  this  guidebook  is  addressed  primarily  to  members 
of  system  Program  Offices  (POs)  who  are  responsible  for  software  aspects  of 
system  programs,  and  in  part  to  personnel  of  supporting  contractors- -although 
the  guidebook  is  not  intended  and  should  not  be  used  as  a  contractual  document . 
If  improvements  are  to  occur,  those  are  the  people  who  must  have  a  common  under¬ 
standing  of  the  system  specification  development  and  functions.  \t  the  same 
time,  it  is  recognized  that  a  PO's  approach  to  the  system  specification  is  con¬ 
strained  by  basic  program  management  policies  that  are  determined,  for  each 
program,  at  or  above  the  Program  Manager  level;  hence,  the  discussions  also 
touch  on  certain  areas  which  appear  to  merit  attention  by  those  hicher-level 
manaeers. 
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The  organisation  and  content  of  material  presented  in  following  sections 
and  appendices  of  this  guidebook  are  summarized  below. 

Section  2,  Model  Concepts,  is  devoted  to  a  description  of  the  system  speci¬ 
fication  development  process.  Emphasis  is  placed  on  describing  the  levels  and 
nature  of  system  engineering  studies  which  are  normally  needed- -i.e.  ,  not 
necessarily  typical  in  practice- -to  develop  comprehensive  requirements  informa¬ 
tion  in  areas  that  are  significant  to  system  data  processing  functions  and 
performance.  One  objective  of  this  section  is  to  outline  the  manner  in  which 
the  technical  process  can  be  planned  and  managed  systematically  within  the 
framework  of  program  management  policies  and  milestones  established  in  such 
current  documents  as  AFR  800-2  and  AFR  57-1.  Key  elements  of  coverage  include 
the  following: 

a.  Levels  of  system  engineering  studies  are  described  ranging  from  derivation 
of  operational  requirements  through  functional  analysis,  advanced  develop¬ 
ment,  and  trade  studies  leading  to  system/ system  segment  design. 

b.  Levels  and  objectives  of  the  technical  steps  are  related  to:  phasing  of 
the  system  program,  from  issuance  of  a  Statement  of  Operational  Need  (SON) 
through  conceptual  and  validation  phases;  identified  roles  of  Government 
agencies  and  contractors;  and  key  areas  of  the  system  specification  content 
affecting  computer  resources. 

c.  Technically,  the  focus  of  discussion  is  on  system  engineering,  which  is 
characterized  by  concern  with  functional  analysis  and  design  at  the  system 
level.  However,  the  description  also  identifies  activities  at  various 
stages  of  the  overall  process  which  require  significant  support  by  special¬ 
ists  in  software  engineering. 

Section  5,  Issues  and  Problem  Areas,  identifies  selected  areas  in  which 
problems  have  been  encountered  pertaining  to  development  and  uses  of  the 
system  specification  in  electronic  system  programs.  This  section  includes 
discussions  of  the  following  topics: 


a.  Intended  functions  of  the  system  specification  in  a  model  svstem  program., 
in  relation  to  functions  of  other  specification  types.  In  established 
policy  and  practice,  the  system  specification  has  some,  but  limited,  uses 
as  a  contractual  compliance  document.  Basically,  equipment  and  computer 
program  elements  of  a  system  are  acquired  most  directlv  acainst  lower-level 
(configuration  item)  specifications. 

b.  Current  problems  associated  with  PO  manpower  and  increasing  prominence  of 
commercial  components.  This  discussion  outlines  some  novel  uses  of  the 
system  specification  which  have  been  employed  or  suggested  to  alleviate 
difficulties  being  experienced  in  recent  system  programs. 

c.  Factors  of  risk.  In  general,  "program  risks"  involve  deficiencies  of 
either  a  technical  or  management  nature,  or  both.  This  discussion  suggests 
that:  few  if  any  system  program  failures  have  been  known  to  result  ^rom 
software  technical  limitations  as  such;  the  serious  troubles  encountered  in 
actual  practice  have  typically  been  matters  of  (1)  inadequate  definitions 
of  requirements,  via  system  engineering  effort,  and  (2)  inadequate  program 
planning  and  management.  These  factors  point  to  a  general  need  for  wider 
use  of  the  validation  phase  as  a  device  for  reducing  those  prominent  risks. 

Appendix  A,  System  Specification  Preparation,  is  provided  herein  as  a  pre¬ 
liminary  basis  for  further  development  of  guidance  pertaining  to  preparation  of 
the  system  specification  in  accordance  with  format  and  content  instructions  con¬ 
tained  in  Appendix  I  of  MTL-STD-490.  A  complete  guide  to  interpret  those 
instructions  comprehensively  for  electronic  systems  is  needed  but  is  not  yet 
available.  Although  clearly  in  line  with  this  guidebook's  title  and  objectives, 
the  adequate  develooment  of  such  guidance  will  require  a  longer-term  effort. 

As  a  sample  approach,  however,  Appendix  A  presents  portions  of  a  guide  which 
was  prepared  at  The  Aerospace  Corporation  for  space  systems,  together  with 
supplementary  comments  on  a  few  of  the  paragraphs  considered  to  be  of  particular 
importance  to  software/computer  resources.  Portions  covered  in  the  sample  are 
confined  to  Section  5,  Requirements,  of  the  system  specification. 


Appendix  B,  Sample  Paragraph  3.3.S,  contains  a  sample  of  system  specifica¬ 
tion  content  dealing  with  design  and  construction  standards  for  computer 
programs  which  has  been  developed  at  ESD  and  proposed  for  general  use.  The 
appendix  includes  comments  by  this  guidebook  author  on  suitability  of  the 
proposed  sample  in  relation  to  proper  content  and  functions  of  the  system  speci¬ 
fication.  Overall,  this  paragraph  deserves  more  careful  and  sparing  treatment 
than  it  has  generally  received. 

Appendix  C,  Sample  Functional  Flow  Block  Diagrams,  presents  examples  of 
functional  flow  diagrams  prepared  for  system  data  nrocessing  functions,  based 
on  format/content  instructions  contained  in  DI-S-3604.  These  samples  illus¬ 
trate  one  prominent  form  of  system  engineering  documentation  discussed  in  the 
preceding  Section  2  (Model  Concepts) ,  which  should  normally  be  included  as  a 
part  of  the  information  furnished  in  paragraph  3.1.4  of  the  system  specifica¬ 
tion. 

Appendix  D  and  Appendix  F.  contain  lists  of  the  source  references  and  abbre¬ 
viations,  respectively,  that  are  cited  and  used  in  the  guidebook  text. 


NOTE  TO  READERS 


■Ate  to  widespread  conflicts  in  accepted  definitions,  use  of  the  term  "soft¬ 
ware'  has  been  systematically  avoided  in  most  official  Air  Force  documents 
dealing  with  acquisition  management,  for  many  years  (viz.,  AFR  800-14,  AFR  65-3, 
Mil. -STD-483.  Mil -STD-1 S21A1 .  "Computer  program"  does  have  a  recognized  Air 
Force  definition  (e.g.,  in  MIL-STP-483)  which  is  relatively  precise  and  much 
less  subject  to  diverse  interpretations.  "Software"  is  used  in  this  guidebook 
because  it  is  established  as  a  part  of  the  SAM  guidebook  series  title.  However, 
readers  are  requested  to  note  that  its  intended  meaning,  throughout  the  text 
herein,  is  exactlv  equivalent  to  "computer  program(s)". 
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SECTION  2 


'DDE I.  CONCEPTS 


1  v 


Air  Force  policies  and  guidance  for  acquisition  managment  have  lone  been 
based  on  the  use  of  a  "model"  system  program  as  the  essential  reference  frame¬ 
work  for  managing  the  development  of  new  svstems.  The  model  for  a  svster  procra' 
consists  basically  of  a  nredetermined  scenario  of  management  actions  and  event.' 
keyed  to  a  standard  sequence  of  system  li fe-cvclo  nhases.  It  reflects  estab¬ 
lished  relationships  and  responsibilities  of  implement  lng/narticioatin'-  organi¬ 
zations  and  incorporates  a  spectrum  of  associated  standards  and  guidance  per¬ 
taining  to  objectives,  procedures,  and  criteria  affecting  tiie  prescribed  action' 
and  events. 

Actions  and  events  identified  in  the  model  include  ones  for  which  some 
requirements  are  mandatorv  and  others  optional,  in  varying  degrees.  While  the 
construction  and  use  of  such  a  model  assumes  that  all  system  nrograms  will  have 
a  broad  range  of  common  characteristics,  it  is  also  recognized  that  every  indi¬ 
vidual  program  is  likely  to  depart  from  the  model  in  some  of  its  aspects.  Hov - 
ever,  the  important  underlying  principle  is  that  of  "management  by  exception"-- 
i.o.,  by  having  predetermined  solutions  for  the  planning  and  conduct  of  major 
parts  of  all  programs,  each  Program  Manager  should  have  relatively  more  time  and 
freedom  for  attention  to  the  special  aspects  of  his  individual  program. 

Thus,  the  assumption  that  standards  must  be  "tailored"  to  the  needs  of  each: 
program  is  inherent  in  the  model  approach,  although  the  widespread  recent  empha¬ 
sis  which  has  been  placed  on  the  tailoring  activity  as  such  has  caused  manv 
Program  Managers  to  lose  sight  of  the  fact  that  the  converse  is  also  true- -in 
that,  the  model  must  first  be  known  and  observed  before  it  can  be  sensibly 
tailored.  Considering  the  complex  spectrum  of  tasks  involved  in  managing  the 
acquisition  of  an}-  large  military  system,  promising  alternatives  to  the  develop¬ 
ment,  continuing  refinement,  and  use  of  the  model  approach  do  not  exist. 

This  section  outlines  a  model  approach  to  developing  the  system  specifica¬ 
tion  for  a  large  electronic  system.  The  approach  is  described  with  emphasis  on 
what  should  occur,  in  the  light  of  demonstrated  technical  and  management  needs 
of  the  nrocess,  rather  than  what  has  been  necessaril”  tvpicul  in  actual 


practice.  In  accordance  with  purposes  of  this  guidebook,  attention  is  focused 
on  early  phases  of  the  life  cycle,  and  on  the  scope  and  nature  of  technical 
requirements  information  to  be  collected,  analyzed,  and  organized  as  a  sound 
basis  for  initiating  the  full-scale  development  of  a  complex,  computer-based 
system. 


2 . 1  Phasing  Considerations  -  General 

The  model  adopted  for  overall  phasing  of  the  system  specification  develop¬ 
ment  is  illustrated  in  Figure  2-1.  This  model  is  chosen  primarilv  because  it  is 
one  which  can  provide  for  meeting  needs  of  the  technical  process,  and  because  it 
also  permits  meeting  the  requirements  of  many  established  standards  which  apply 
during  conceptual  and  validation  phases  of  system  programs.  At  the  same  time, 

: t  incorporates  certain  assumptions  about  electronic  system  programs  which  are 
not  explicitly  confirmed  or  emphasized  in  current  top-level  policies  for  major 
defense  systems,  nor  clearly  exemplified  in  most  of  the  actual  practice.  Prin¬ 
ciple  points  of  the  diagram  to  be  expanded  upon  in  following  sections,  including 
some  potential  points  of  issue,  are  summarized  as  follows: 

a.  Development  of  a  large,  digital  computer-based  system  requires  full  utili¬ 
sation  of  available  system  engineering  resources,  over  the  maximum  available 
time  soar..  Significant  initial  steps  in  the  total  process  must  be  accom¬ 
plished  during  the  preconceptual  period,  in  conjunction  with  and  following 
initial  identification  of  the  operational  need. 

b.  Alternative  solutions  to  meeting  mission  needs  of  the  operational  command 
are  evaluated  preceding  and  during  the  conceptual  phase  (by  the  implementing 
command),  resulting  normally  in  selection  of  a  system  design  at  the  level  of 
system  segments/functional  areas.  The  initial  system  specification  includes 
firm  system  functional ,  performance,  and  interface  requirements,  and  alloca¬ 
tions  of  those  to  the  system  segments.  Otherwise,  it  should  provide  maximum 
latitude  for  alternative  design  solutions,  below  the  segment  level. 

At  that  point  in  time--i.e.,  at  the  outset  of  a  validation  pha se--the  system 
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specification  should  exclude  performance  and/or  design  requirements  that 
depend  on  questionable  technology ,  either  hardware  or  soft-ware. 

d.  A  validation  phase  has  not  often  been  conducted  for  electronic  systems, 
possibly  because  the  basic  hardware  is  not  typically  subject  to  risks  that 
can  be  effectively  reduced  through  such  activities  as  hardware  proofing  and 
prototype  demonstration.  However,  the  typical  problems  that  do  occur  indi¬ 
cate  that  a  validation  phase  should  normally  be  mandatory,  for  the  primary 
objectives  of  flj  accomplishing  sound  management  planning  and  (21  completing 
the  definitions  of  requirements  for  the  system  and  its  configuration  items 
at  levels  that  are  adequate  for  undertaking  the  system  full-scale  develonment . 

Later  subsections  of  this  section  are  organized  to  correspond  individually 
with  the  three  periods  of  time  indicated  above  in  Figure  2-1.  Tne  period 
labeled  "Preconcept ual"  in  the  diagram  represents  the  period  of  program  initi¬ 
ation,  for  which  requirements  governing  formal  documents  to  be  prepared  by  the 
commands  and  processed  through  Headquarters  U.S.  Air  Force  (HQ  USAFj  are  pre¬ 
scribed  in  AFR  57-1  (12  June  1979).  Significant  aspects  of  those  formal  require¬ 
ments  to  be  considered  in  relation  to  the  technical  program  are  summarized 
briefly  as  follows: 

Tne  potential  beginning  of  a  system  acquisition  occurs  when  an  operational 
command  identifies  a  need  for  improved  capabilities  to  perform  its  operational 
mission,  in  the  course  of  on-going  analyses  of  its  ability  to  achieve  assigned 
mission  objectives.  Through  joint  analysis  and  coordination  with  other  commands, 
including  AFSC,  the  need  is  documented  in  the  form  of  a  Statement  of  Operational 
Need  SON)  and  submitted  to  HO  USAF  for  evaluation. 

The  SON  evaluation  stage  may  include  the  preparation  of  a  Mission  Element 
Need  Statement  (PEN'S1  by  HO  I'SAF  for  submittal  to  the  Secretary  of  the  Air 
Force  if  indicated  by  size,  scope,  or  other  criteria  which  would  indicate  a 
major  defense  system  or  Air  Force  Designated  Acquisition  Program.  (AFDAP). 
Validation  of  the  SON  or  approval  of  the  PEN'S  constitutes  the  milestone  zero 
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decision,  authorizing  commitment  of  resources.  These  actions  are  documented 
in  the  Procram  Management  Directive  (PMTM  issued  by  Hn  USAF  to  authorize  formal 
initiation  of  the  conceptual  phase. 

When  the  SON  has  minor  impact  or  involves  minor  risk,  milestone  decision 
authority  mav  be  delegated  to  the  implementing  command,  through  issuance  of  a 
PM?  in  which  HQ  USAF  snecifies  limiting  thresholds,  constraints,  and  objec¬ 
tives  for  the  program. 

As  submitted  by  the  operational  command,  the  SON  itself  must  be  confined 
to  documenting  the  need  or  deficiency  in  functional  terms,  without  specifying 
or  recommending  a  specific  solution.  However:  (a)  it  mav  include  an  attach¬ 
ment  which  identifies  alternative  candidate  solutions;  and  (bi  further  studies 
by  other  commands  (notably,  AFSC)  are  to  be  accomplished  and  reported  during 
the  period  of  SON  evaluation. 

2.2  The  System  Engineering  Process 

Considered  very  generally,  system  engineering  is  the  multi -disciplinary 
activity  which  begins  with  functional  analysis  and  arrives  at  a  total  system 
design,  through  a  process  which  considers  and  evaluates  a  spectrum  of  military, 
economic,  and  technical  variables  that  are  relevant  to  candidate  approaches. 

The  process  has  been  described  more  specifically  as  consisting  of  the  following 
principal  steps: 

a.  The  first  step  is  to  identify  the  mission  element  need  to  be  met  by  the 
system,  e.g.,  as  stated  in  the  SON,  and  translate  that  need  and  its  sub¬ 
elements  into  major  functions  of  a  projected  system.  For  example,  if  the 
need  relates  to  continental  defense  against  a  cruise  missile  threat,  the 
analysis  might  result  in  identifying  such  major  functions  as  air  surveil¬ 
lance,  target  identification,  weapons  control,  and  battle  assessment. 
Insofar  as  possible,  emphasis  is  maintained  purely  on  functions  without 
regard  to  whether  they  will  be  performed  by  people,  hardware,  or  software. 
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b.  Each  function  is  analyzed  in  relation  to  the  projected  military  environment 
to  identify  subfunctions  and  associated  performance  requirements.  Perfor¬ 
mance  requirements  are  matters  of  speeds,  capacities,  accuracies,  and 
similar  criteria  which  bear  on  the  manner  in  which  each  function  must  be 
accomplished.  This  step  mav  involve  analysis  and  evaluation  of  alternative 
solutions,  at  the  functional  level.  It  also  includes  the  identification 

of  functional  interactions  (interfaces)  with  other,  existing  systems. 

c.  Alternative  approaches  to  design  of  the  system- -i.e. ,  in  terms  of  its  physi¬ 
cal  configuration- -are  identified,  initially  in  terms  of  major  subsystems 

or  system  segments*,  and  trade  studies  are  performed  as  needed  to  select  a 
preferred  design  solution  at  that  level. 

Those  steps  are  not  intended  to  be  performed  discretely  in  the  sequence 
outlined.  Each  step  typically  imposes  needs  to  iterate  earlier  steps;  and  the 
design  solution  tends  to  result  from  a  process  of  successive  approximations. 

One  inherent  objective  is  to  arrive  at  an  end  design  which  fully  reflects  and 
is  traceable  to  the  basic  functional  and  performance  requirements  derived  from 
identified  needs  of  the  military’  mission. 

Figure  2-2  summarizes  the  basic  process  described  above,  and  also  suggests 
that  elements  of  this  general  functional  analysis/design  approach  continue  to 
apply  at  each  succcssivelv-lower  level  of  design  as  it  occurs  during  a  system 
program.  Although  labeled  as  the  "system"  engineering  process,  it  clearly 
shifts  at  later  stages  to  the  levels  of  engineering  design  for  which  respon¬ 
sibilities  are  assigned  to  technical  specialists  in  the  system  hardware  and 
software  components. 

The  fact  that  the  term  "design"  applies  at  many  level'  has  significant 


*For  Air  Foret  systems,  this  step  must  include  the  application  of  acquisition 
management  as  well  as  technical  criteria.  In  this  context,  the  terms  "sub¬ 
system",  "svstem  segment",  and  "funct'. onal  area"  are  generally  equivalent, 
with  the  exception  that  instructions  provided  in  Appendix  III  of  MIL-STD-482 
mav  apply  in  special  cases. 
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BASIC  SYSTEM  ENGINEERING  PROCESS  -  SYSTEM  LEVEL: 


•  IDENTIFY  SYSTEM  RJNCTIONS 

i 

•  EXPAND  SYSTEM  FUNCTIONS  & 
DEFINE  PERF/DESIGN  RQMTS. 

I 

•  PERFORM  TRADE  STUDIES  X 

ALLOCATE  FUNCTIONS 
TO 

SYSTEM  SEGMENTS 


LEVELS  OF  ANALYSIS  &  DESIGN: 


-  SYSTEM 


- SEGMENT 


-  Cl/CPCI 


-  COMPONENT 


Fipure  2-2.  Generalized  Elements  of  the  System  F.npineerinr  Process 
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management  implications,  as  well  as  technical,  throughout  the  course  of  a 
svstein  acquisition.  Generally,  acquisition  responsibilities  are  assigned  to 
Doli  components,  commands,  agencies,  contractors,  and  their  organisational 
units  at  identified  levels  of  system  or  configuration  item  design.  Management 
techniques  are  associated  with  organizational  responsiblities  at  all  levels, 
which  depend  upon  the  technical  design  solutions  and  at  the  same  time  impose 
constraints  on  the  design  process.  Those  tend  to  be  most  visible  in  the  form, 
of  policies  that  each  system  segment  and  configuration  item  must  be  defined  in 
such  a  way  that  responsibilities  for  its  development  can  be  assigned  to  a 
single  contractor/agency ,  and  of  subsequent  requirements  to  maintain  traceable 
interrelations  of  technical  products  with  such  management  instruments  as  state¬ 
ments  of  work,  specification  trees,  organization  charts,  and  work  breakdown 
structures . 

The  relevant  point  for  purposes  of  this  discussion,  however,  is  that  the 
very  first  design  decision  which  occurs  to  initiate  that  whole  general  pattern 
is  the  one  which  identifies  the  new  system  itself.  While  that  decision  is 
closelv  linked  with  the  analysis  of  mission  needs  for  which  an  operational 
command  is  primarily  responsible,  it  is  neither  a  direct  result  nor  a  direct 
purpose  of  the  mission  analysis  as  such.  Rather,  it  should  normally  be  a 
result  of  associated  system  engineering  efforts,  preferably  carried  out  by 
activities  which  can  provide  continuity  with  later  efforts  by  the  imolementing 
command  to  develop  the  system  specification.  The  description  of  early  activi¬ 
ties  provided  in  the  following  section  is  based  on  this  general  premise. 


r 
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Generation  of  the  System  Concept 


This  description  outlines  the  nature  of  preliminary  technical  tasks  which 
should  be  accomplished  prior  to  the  beginning  of  formal  specification  prepa¬ 
ration.  The  specific  technical  steps,  and  the  total  tine  span  over  which 
preliminary  studies  should  occur,  are  subject  to  wide  variations  for  different 
systems.  Hence,  emphasis  in  this  description  is  placed  on  levels  of  design 
decisions  and  npes  of  related  technical  information  which  should  result  from 
these  early  studies,  rather  than  on  a  fixed  flow  of  events. 

For  an  electronic  (information  processing)  system,  the  first  and  major 
objective  of  this  period  as  a  whole  is  to  arrive  at  a  firm  definition  of  the 
system  concept.  Associated  objectives  are  to  acquire  and  document  information 
pertaining  to  system  requirements,  design  approaches,  and  constraints,  initi¬ 
ating  the  essential  base  of  background  technical  data  which  will  be  needed 
for  continued  use  and  expansion  at  later  stages. 

2.3.1  Initial  System  Concept 

Not  all  SONs  are  subject  to  solution  by  new  system  developments.  Mien 
they  are,  however,  the  initial  concept  for  a  new  system  is  likely  to  he 
related  to  the  mission  analysis  activities  which  led  to  identifying  the 
operational  need  or  deficiency.  Such  factors  as  obsolescent  technology, 
opportunities  to  exploit  new  technology,  and  known  changes  in  the  threat 
environment  have  often  pointed  already  to  the  general  nature  of  a  possible 
new  system  by  the  time  they  are  reflected  in  statements  of  need  for  improved 
operational  capabilities.  A  new  or  modified  computer-based  system  is  clearly 
suggested,  for  example,  by  the  identified  inability  of  a  command  to  handle 
information  processing  and  communications  functions  associated  with  a  new 
surveillance  technique,  weapon,  threat,  or  area  of  military  operations. 

While  associated  information  about  the  system  functions  and  probable 
design  characteristics  may  be  fairly  extensive  at  the  outset  in  some  cases, 
the  initial  svstem  concept  is  rarelv  adequate  as  a  basis  for  starting  the 
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svstem  pros ran;.  However,  the  concept  of  a  system,  as  such,  is  an  indispensable 
starting  point  and  guide  for  the  further  studies  outlined  below.  In  the  course 
of  further  examination,  the  initial  concept  may  be  confirmed  and  refined, 
altered,  or  perhaps  abandoned  in  favor  of  alternative  solutions  to  the  opera¬ 
tional  need. 

1.3.2  Operational  Requirements  Analysis 

Expressed  in  summary  terms,  purposes  of  operational  requirements  analysis 
are  to  identify  elements  and  subelements  of  the  operational  command  mission 
which  the  projected  svstem  is  intended  to  support,  translate  those  into  system 
functions,  and  identify  performance  requirements  associated  with  the  functions. 
"Requirements"  refers  here  to  functional  and  performance  characteristics  of  the 
projected  svstem,  as  distinguished  from  "needs"  which  refer  more  directlv  to 
the  command  mission.  Except  for  that  difference  in  orientation,  this  first- 
level  system  analysis  activity  is  necessarily  carried  out  in  close  coordination 
with,  and  with  continuing  active  participation  by,  the  operational  command. 

Once  designed,  it  may  be  assumed  that  the  electronic  system  will  consist 
o:  such  elements  as  digital  computing  and  communications  equipment,  computer 
programs,  personnel,  facilities,  and  possibly  sensors  or  vehicles.  In  the 
operational  analysis  activity  as  such,  however,  the  focus  is  on  the  scope  and 
nature  of  mission  elements,  relevant  factors  of  the  operational  environment, 
and  derived  requirements  for  data  outputs,  inputs,  and  nrocessing.  It  is  not 
normally  practical  to  exclude  design  considerations  altogether,  particularly 
in  view  ot  the  fact  that  this  level  of  analysis  must  be  iterated  and  refined 
at  later  stages  ot  the  system  program.  However,  tbev  should  not  be  permitted 
to  u i vert  attention  from  the  mainline  pumose  of  identifying  and  defining 
functional  requirements  in  the  operational  context,  since  those  will  become 
the  working  criteria  against  which  design  alternatives  are  selected  and 
evaluated. 

Methods  and  areas  of  emphasis  for  early  stages  of  the  analysis  necessarily 
vnp’  as  a  function  of  the  nature  and  complexity  of  the  mission  elements 
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involved,  levels  of  information  already  acquired  dv  the  operational  command 
organization,  and  similar  factors  affecting  the  degree  to  which  an  initial 
system  concept  is  related  to  firmly  prescribed  mission  tasks.  Successive 
iterations  m  some  aspects  of  the  activities  outlined  below  will  be  required 
as  the  program  moves  into  later  stages  to  arrive  at  the  comprehensive  defini¬ 
tions  of  operational  requirements  which  will  be  needed  before  the  system, 
specification  can  eventually  be  completed. 

a.  The  initial  task  is  to  translate  mission  elements  into  identified  functions 
of  the  projected  system.  Generally,  this  translation  consists  of  identi¬ 
fying  operational  processes  necessary  to  accomplish  the  assigned  military 
responsibilities  and  objectives;  and  it  often  involves  significant  atten¬ 
tion  to  delineating  the  system  mission  scope,  as  well  as  its  nature.  In 
some  cases,  answers  to  auestions  in  this  area  may  be  clearly  indicated  in 
the  SON.  In  others,  substantial  effort  may  be  needed  to  explore  relations 
of  the  identified  need  or  deficiency  to  a  viable  system  concept.  Occa¬ 
sionally,  circumstances  may  point  to  the  advisability  of  identifying  a 
limited  set  of  functions  to  be  further  defined  for  the  given  system 
program,  reserving  others  for  longer-range  planning.  However,  to  provide 

a  sound  basis  for  the  system  program  at  hand,  an  essential  objective  of 
this  activity  is  to  arrive  at  a  definition  of  the  system's  major  functions 
in  terms  of  both  their  focus  and  clearly-delineated  boundaries. 

b.  The  functions  of  an  electronic  system  are  characteristicallv  functions  of 
data  processing.  Effectiveness  of  the  svstem  as  a  device  to  support  a 
military  mission  will  eventually  be  assessed  in  terms  of  its  abilitv  to 
provide  data  (or  information!  outputs  which  meet  criteria  in  such  areas 
as  accuracy,  timeliness,  and  sufficiency.  Thus,  the  technical  content 

of  the  analysis  should  consist  in  large  part  of  identifying  the  required 
data  outputs,  then  tracing  the  manner  in  which  those  outputs  can  be  gener¬ 
ated  through  processing  operations  performed  on  available  system  inputs. 

For  early  purposes- -i .e. ,  of  defining  the  system  concept  at  levels  ade¬ 
quate  for  initiating  a  scheduled  acquisition  program- -informat ion  about 
types  of  inputs,  processing  operations,  outputs,  and  associated  performance 
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requirements  should  be  acquired  and  documented  at  the  relatively  gross 
level  of  maior  system  functions.  These  maior  functions  are  often  identi¬ 
fied  to  correspond  with  areas  of  the  assigned  militar>'  mission  (e.g., 
Operational  Planning,  Weapons  Control,  Strike  Effect  Evaluation).  To 
sunnort  continuation  of  the  system  Program,  however,  this  effort  must  also 
include  the  systematic  collection  and  documentation  of  information  in  the 
related  areas  outlined  below. 

The  documentation  of  detailed  operational  reauirements  at  lower  levels 
should  be  initiated  as  early  as  possible,  and  expanded  as  rapidly  as 
events  and  available  manpower  will  permit.  Eventuallv- -preferablv  before 
the  end  of  the  validation  phase --precise  and  detailed  definitions  will  be 
needed  for  every  single  type  of  data  input,  processing  operation,  and  data 
output.  Inadequacies  in  this  area  are  a  chronic  problem,  due  to  the 
tvpically  massive  quantities  of  that  information.  While  there  are  auto¬ 
mated  techniques  that  can  assist  in  some  of  its  aspects,  the  basic  task 
of  identifying  and  verifying  user  requirements  associated  with  each  and 
every  data  item  is  inescapably  manual.  As  a  rule,  the  collection  of 
properly-documented  data  item  requirements  for  a  large  fixed  data  base, 
and  for  external  message  interfaces  with  other  existing  systems,  should 
be  well  under  wav  by  the  time  the  SON  is  validated. 

As  indicated  above,  the  operational  requirements  analysis  is  primarily 
concerned  with  functions  and  performance.  However,  design  considerations 
cannot  be  excluded  altogether,  since  they  inevitably  influence  the  nature 
and  form  of  maior  functions  chosen  for  analysis,  even  at  the  system  level. 
Maior  design  constraints  are  often  imposed  explicitly  by  policy,  or 
implicitly  bv  obvious  considerations  of  technology  or  expense;  functions 
as  such  will  he  defined  and  careful lv  analyzed  only  when  there  are  reason¬ 
able  grounds  to  believe  they  can  be  implemented.  Hence,  a  base  of  design 
documentation  should  be  initiated  at  the  outset  which  can  be  progress ivelv 
expanded  and  refined  during  the  course  of  later  activities.  At  each 
stage,  it  should  identify  known  design  constraints,  design  alternatives, 
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and  identified  questions  of  feasibilitv  deserving  further  studv.  At 
early  stapes,  particular  attention  is  needed  to  identifying  < 1  ;  design 
assumptions,  where  they  may  affect  the  functional  analysis,  and  <2  > 
needs  for  special  research  or  feasibilitv  studies  which  require  long 
lead  times  to  yield  usable  results. 


2.3.3  Design  Studies 


Current  policies  for  major  defense  system  acquisition  recognize  the  need 
for  design  studies  during  the  preconceptual  period  for  numoses  of  identifying 
and  assessing  alternative  solutions  to  design  of  the  system  as  a  whole.  AFP 
.‘"■1  assigns  responsibilities,  jointly  to  AFSC,  .AFLC,  AFCC,  and  ATC,  to  iden¬ 
tify  constraints  that  limit  alternative  solutions  and  compare  candidate 
alternatives  with  respect  to  technical  and  other  factors  of  feasibility.  In 
conjunction  with  these  activities,  AFSC  must  also  prepare  a  program  management 
plan  for  the  succeeding  phases. 

Major  alternatives  for  electronic  svstems  tend  to  be  matters  of  design  in 
such  areas  as  command  organizational  structure,  geography  or  denlo'-ment,  com¬ 
munications,  and  data  processing  technologies.  Where  significant  questions 
exist,  special  studies  mav  be  indicated  to  assess  alternatives  with  respect 
to  relative  effectiveness,  technical  feasibility,  costs,  development  times,  and 
support  factors.  The  particular  nature  and  emphasis  of  these  studies  should 
generally  be  dictated  by  design  requirements  derived  from  the  preceding  analy¬ 
sis  of  functions  for  the  given  system.  Just  how  far  the  system  design  should 
have  progressed  by  the  end  of  this  period  is  a  question  to  be  resolved  in  the 
light  of  such  considerations  as  the  following: 

a.  The  system  configuration- -and  each  realistic  alternative,  if  any  exist-- 
must  be  determined  at  a  level  which  is  adequate  for  program  management 
planning,  purposes.  Estimates  of  feasibility ,  costs,  procurement  approach, 
and  schedules  should  be  based  on  Projected  system  support,  including 
training  and  training  equipment,  as  well  as  system  operational  functions, 

I  .  in  accordance  with  general  Air  Force  policy,  unnecessary  limitations  to 
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subsequent  design  solutions  by  competing  sources  must  be  avoided.  This 
policy  is  most  clearly  pertinent  to  design  in  the  areas  of  system  hard¬ 
ware  and  software  components. 

However,  questions  of  system  configuration  which  require  long  lead-times 
for  their  solution,  or  which  must  be  resolved  primarily  through  inter -command 
efforts  and  decisions,  should  be  firmlv  resolved  before  the  next  phase  begins. 
Mich  questions  tend  to  be  characteristic  of  electronic  systems.  As  one  example, 
extensive  studies  and  coordination  were  needed  over  a  lengthy  period  to  arrive 
at  a  viable  gross  configuration  for  an  air  defense  svstem  in  terms  of  numbers 
and  locations  of  direction  centers,  taking  into  account  interactive  relation¬ 
ships  with  surveillance  radar  locations,  command  centers,  air  bases,  communica¬ 
tions,  and  command  organizational  units.  Decisions  at  that  level,  which 
establish  a  known  framework  of  maior  parameters  and  boundaries  for  the  system, 
are  generally  essential  as  a  basis  for  delimiting  the  potential  scope  and 
emphasis  of  system  engineering/ informat  ion  processing  analyses  at  later 
stages . 
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2 . 4  The  Initial  System  Specification 

The  Program  Management  Directive  (PMP1  issued  by  Hn  * i: Ar  to  initiate  the 
conceptual  phase  includes  directions  for  funding,  schedules,  approval  actions, 
and  program  management  objectives  which  are  tailored  to  each  program.  The 
description  provided  in  this  section  assumes  that  the  recognized  nrimar'  tech¬ 
nical  objective  of  this  nhase,  for  a  major  electronic  system,  is  to  develop  ai. 
adequate  initial  system  specification. 

The  system  program  is  managed  during  this  phase  by  the  Program  Office  (TO' 
established  by  AFSC  in  response  to  the  PMD.  The  PO  is  the  designated  central 
office  having  Air  Force  responsibility  for  planning  and  management  of  the 
program,  as  a  whole,  including  contracting,  logistic  sunnort ,  program,  control, 
and  related  support  management  areas  as  well  as  engined  ing.  Participation 
by  other  commands  and  Government  agencies  is  provided  through  representation 
in  the  PO  organization.  The  actual  conduct  of  continued  studiec  in  the  techni¬ 
cal  (engineering':  area  is  carried  out  with  additional  support  by  personnel  of 
AFSC  laboratories ,  a  Federal  Contract  Research  Center,  or  svstem  engineering 
contractors. 

2.4.1  System  Engineering  Analysis 

Maior  types  of  activity  involved  in  the  process  of  developing  information 
tc  be  provided  in  for  with)  the  system  specification  are  outlined  in  Figure 
2-5.  Although  the  activities  are  highly  interactive,  as  the  figure  suggests, 
the  effort  as  a  whole  should  be  planned  and  structured  to  emphasize  the 
immediate  goal  of  yielding  information  in  the  many  categories,  and  at  the 
levels,  which  the  initial  svstem  specification  requires.  Once  the  conceptual 
phase  formalb  begins,  the  end  products  of  these  efforts  must  generally  be 
accomplished  on  a  tine  schedule  which  is  relatively  short  and  fixed,  as 
compared  with  the  p-ecodir  period,  'lowever,  demands  to  maintain  flexibility 
are  inherent  in  the  svstem  engineering  process.  To  the  degree  feasible, 
efforts  should  be  planned  and  managed  to  provide  for  repetitions,  expansion, 
or  redirection  as  indicated  hv  actual  progress  and  results. 
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Figure  2-4  identifies  a  sequence  of  major  tasks  and  logical  steps  involved 
in  the  process  represented  in  the  preceding  figure.  Narratives  below  are 
ke\-ed  to  block  numbers  shown  for  the  steps.  Cm  the  whole,  this  description 
is  limited  to  a  summary  of  the  "mainline”  process,  the  full  scope  of  activi¬ 
ties  in  a  given  actual  case  is  clearlv  much  more  complex. 

TASK  1  -  FlA'CTIONAl.  ANALYSIS 

The  objective  of  this  task  is  to  collect,  organize,  and  analvze  informa¬ 
tion  about  system  operational  functions  which  will  provide  iai  direct  innuts 
to  system  definition  and  performance  characteristics  nor". ions  of  the  system 
specification  and  fb'  the  functional  requirements  basis  for  further  study  of 
support  functions  and  requirements/constraint?  for  system  design. 

Block  I.]  Collect  and  Organize  Technical  Data.  .An  essential  early  step  is  to 
establish  a  data  hank  of  existing  information  about  the  system.  This  activity 
should  begin  by  compiling,  reviewing,  and  assessing  the  source  documentation 
resulting  from  the  preconceptual  period  studies.  Centralized  files  should  be 
organized  to  provide  for  continuing  access  and  expansions  as  the  analysis 
proceeds . 

Block  1.2  Develop  Functional  Flow  Diagrams.  This  activity  is  based  on  opera¬ 
tional  requirements  and  gross  system  design  decisions  resulting  from  earlier 
studies;  it  includes  additional  studies  to  expand  that  information  as  necessary 
to  ensure  its  completeness  and  accuracy  with  respect  to  military  objectives, 
constraints,  and  the  operational  environment.  The  activity  consists  of  devel¬ 
oping  functional  flows  and  systematically  documenting  those  in  forms  suitable 
for  use  in  subsequent  steps  of  the  analysis.*  Initially,  system  requirements 
are  translated  into  one  top-level  diagram  which  identifier  the  gross  mission 
operations  together  with  test,  production,  deployment,  and  support  functions. 


*Khile  functional  flow  diagram  formats  are  optional,  clear  and  consistent 
rules  for  a  selected  approach  should  be  established  at  the  outset  of  each 
project.  Fo’'  purposes  of  this  description,  thev  are  assumed  to  be  developed 
in  accordance  with  rules  and  widely-established  uses  of  the  diagrams  as 
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l  ij-ure  2-4.  1  low  of  Major  Technical  Tasks  Conceptual  Phase 


At  this  stage ,  flows  should  be  further  developed  for  the  mission  (operational ; 
functions  at  the  first  and  second  levels,  at  a  minimum,  and  at  lower  levels  for" 
selected  subfunctions  as  needed. 

Block  l.B  Initiate  Requirements  Allocations.  The  systematic  allocation  of 
reouirements  to  system  segments  is  initiated  at  this  stage  to  provide  a  basis 
for  subsequent  studies  of  design  alternatives  at  lower  levels.  Sestet,  sermcnT s 
(subsystems,  or  runctional  areas)  are  likely  to  have  been  identified  in  a  pre¬ 
liminary  way  at  earlier  points  in  time;  but  their  verification  and  precise 
uelineation  is  a  progressive  process  which  will  not  be  fully  completed  until 
the  end  c •  f  the  validation  phase. 

This  step  should  include  reviewing  and  assessing  one  or  more  proposed 
breakdowns  of  the  system  into  segments  for  soundness  in  the  light  of  available 
criteria.  Each  segment  is  a  major  part  of  the  system  which  lal  is  character- 
iced  as  a  technically-consistent  grouping  of  system  elements  designed  to  perform 
assigned  portions  of  the  system  functions,  and  fb;  represents  an  area  of  devel¬ 
opmental  responsibility  which  must  be  assigned  to  a  single  contractor  or  Govern¬ 
ment  agency.*  This  allocation  activity  itself  serves  to  verify  or  alter  the- 
preliminary  identification  of  system  segments,  in  that  a  sound  breakout  should 
permit  all  requirements  to  be  precisely  allocated  without  creating  complex 
interfaces  among  the  segments. 

The  allocation  process  begins  with  system  functions  identified  in  the 
preceding  step.  It  consists  of  assigning  the  functions,  subfunctions,  and 
performance  requirements  to  the  segments  in  such  a  way  as  to  identify  technical 
design  criteria  which  will  apply  to  specifying  combinations  of  equipment,  per¬ 
sonnel,  and  facilities  needed  to  perform  each  function.  Systematic  documenta¬ 
tion  is  a  fundamental  necessity,  due  to  the  sheer  volumes  of  information 
involved  as  the  process  continues  during  this  and  subsequent  tasks.  Tvpes  of 
svstem  engineering  documents  which  should  be  generated  bv  this  activity- -and 
controlled  during  later  expansions- -are  exemplified  by  the  Requirements  Allo¬ 
cations  Sheets  and  Schematic  Block  Diagrams  described  in  D1-S-SP05  and  -3fcD“. 


*This  is  not  to  say  that  each  segment  must  be  assigned  to  a  separate  contrac¬ 
tor/ agency.  All  requirements  max-  he  assigned  to  a  single  contractor;  however, 
the  breakout  still  serves  significant  purposes  of  management  visibility  and 
control  fo1"  both  the  Air  Force  and  prime  contractor. 
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Block  1.4  Evaluate  Requirements  for  Automation.  This  activity  consists  of 
analvcing  performance/design  requirements  and  constraints  associated  with 
svster  information  processing  functions  for  man/machine  allocations.  System 
inputs  and  outputs  are  examined  with  respect  to  such  characteristics  as  sources, 
frequencies,  volumes,  formats,  contents,  securitv,  timing,  accuracy,  and  asso¬ 
ciated  implications  for  the  involvement  of  system  personnel  in  their  generation 
or  processing.  Decisions  are  based  on  evaluating  functions  and  requirements  in 
the  light  of  such  factors  as  technical  feasibility,  costs,  timing,  and  inherent 
needs  for  on-the-spot  judgment  or  intervention.  This  analysis  should  proceed 
to  the  point  of  allocating  functions  among  the  following  three  categories: 

a.  Manual  -  essential  decision-making,  coordination,  analysis,  or  control 
functions  to  be  performed  by  conmand  or  staff  personnel  which  do  not 
imply  direct  interaction  with  system  input  or  display  equipment. 

b .  Automated  -  functions  performed  by  equipment  without  manual  intervention . 

c.  Man- Machine  -  functions  performed  primarily  by  personnel,  but  involving 
direct  interaction  with  automated  system  functions/subfunctions  through 
manual  input  and  display  devices. 

This  step  a?  a  whole  should  be  accomplished  comprehensively  for  the  system 
operational  (mission I  functions  and  for  major  support  functions  derived  from, 
the  known  operational  requirements- -for  example,  functions  of  simulation,  data 
recording,  and  data  reduction  involved  in  system  test  and  evaluation  or  train¬ 
ing.  Although  information  about  support  functions  is  likely  to  be  variable, 
particular  effort  should  be  taken  to  ensure  that  general  requirements  are 
identified  that  will  affect  the  scope  of  needs  for  system  personnel ,  hardware, 
and  software. 

liit  significant  initial  result  of  this  activity  is  to  arrive  at  a  first - 
level  separation  of  system  functions  assigned  to  the  two  major  classes  of 
element'-  which  nertortr  data  nrocessing  operations  in  an  electronic  svstem-- 
namel v,  personnel ,  on  the  one  hand,  and  a  set  of  automatic  data  processing 
fhardwarc/software :  elements  on  the  other.  In  the  case  of  personnel ,  this  and 


later  steps  are  directed  towards  (a)  identifying  the  tvpes ,  level-,  and  gen¬ 
eral  characteristics  of  command  and  staff  positions  required  to  perform  the 
identified  manual  and  man -machine  tasks,  including  impact  on  training  needs  and 
the  operational  command  organization,  and  (b)  formulating  human  factors  engi¬ 
neering  requirements  to  be  imposed  on  the  system  data  processing  hardware, 
software,  communications,  and  facilities. 

is  regards  automated  elements,  the  emphasis  at  this  stage  is  or,  collecting 
and  detailing  requirements  for  information  processing  functions  which  will  be 
further  allocated  eventually  as  between  digital  computing/communications 
hardware  and  computer  programs.  Immediate  objectives  are  to  identify  and 
catalog  those  automated  functions  and  derived  performance  requirements, 
encompassing  both  the  purely  automated  functions  and  those  associated  with 
manual  inputs  and  displays. 

Block  1.5  Organize  Requirements  for  Software.  A  final  step  in  this  task  is 
to  integrate  and  organize  data  resulting  from  the  preceding  steps,  and  to 
translate  the  aggregation  of  those  requirements  into  criteria  for  system  com¬ 
puter  programs.  The  process  of  integrating  operational  and  support  require¬ 
ments  must  include  their  evaluation  with  respect  to  such  characteristics  as: 
adequacy  in  meeting  mission  needs  of  the  operational  command;  environmental  and 
organizational  contingencies;  functional  interfaces  with  external  systems/ 
organizations;  generation,  content,  and  uses  of  fixed  data  bases;  and  major 
factors  of  loads,  volumes  of  data,  response  times,  growth  potential,  and 
security. 

The  integrated  requirements  for  automated  functions  are  analyzed  initially 
to  arrive  at  an  overall  assessment  of  the  system  software  characteristics. 

During  later  steps,  hardware  and  software  trade-offs  will  be  examined;  and 
still  later  (during  the  validation  phase),  firmly-identified  characteristics 
of  the  computer  hardware  will  become  a  prerequisite  to  the  identification  of 
computer  program  configuration  items  (CPCTs)  and  the  initiation  of  their 
development  specifications.  At  earlier  phases  of  an  electronic  system  program, 
however,  software  is  the  "lead  item"  unon  whose  characteristics  the  determination 
of  requirements  for  the  system  data  processing  hardware  must  be  based. 
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In  the  system  specification,  software  requirements  will  continue  to  be 
expressed  predominantly  in  terms  of  functions  and  Derformance--and,  in  terms 
of  functions  and  performance  that  will  continue  to  be  shared  with  computer 
hardware.  The  specification  of  software  "design",  as  such,  at  the  system 
specification  level  is  limited  to  fa)  general  design  requirements/constraints 
design  standards  cited  in  paragraph  3.3.8)  and  fh)  the  structuring  of 
software  elements  into  CPCIs  (to  he  accomml ished  during  the  validation  phase,. 

r,  further  examination  of  software  design  approaches  should  be 
rvuieh  as  an  irmn-tant  par*  of  subsequent  steps  at  this  stage ,  in  order  to: 
ver >  :"v  fcasiri" it v  and  como] eteness  of  the  requirements;  identify  and  assess 
s.  at'- of-t  he-n;  t  technique-'  as  they  q.-.piv  to  relevant  functions  - -e.  g. ,  data 
<>ua  -oment ,  tivie-sharmt.  parallel  processing,  communications,  data 
.  . ss  control;  and  furnish  essential  criteria  to  assist  in  determining  require- 

■  vs  ;  or  the  design  of  data  process  in  5;  hardware. 


■  Lug  _  idi:^IGN  TRADE  STUDIES 

This  task  consists  of  a  series  of  systematic  analyses  to  assess  the 
advantages  and  disadvantages  (trade-offs)  of  system  data  processing  design 
alternatives  with  respect  to  both  hardware  and  software.  The  purpose  is  to 
construct  a  rational  set  of  design  concepts--! .e. ,  a  feasible  system  configura¬ 
tion-  -as  a  work i no  basis  for  subsequent  integration  of  system  requirements 
information  during  the  conduct  of  Task  3.  By  this  stage,  it  is  assumed  that 
tnaior  parameters  of  the  system  configuration  have  been  established  through 
p- i • .  decisions,  permitting  taese  studies  to  focus  on  a  relatively  finite 
rais-c  of  design  alternatives..  In  each  case,  the  identification  of  significant 
alternatives  to  examine  is  a  matter  of  technical  judgment  based  on  knowledge 
c;  the  civen  system  requirements  and  constraints,  even  with  those  limitations, 
i t  ;i  not  normally  necessary  or  practical  to  analyte-  all  possible  alternatives 
e --haust. ively.  The  objective  is  to  interrelate  a  set  of  realistic  design 
si--. i; it  ion?  with  system  requirements  in  sufficient  depth,  to  assure  that  the 
root  1  i rement .-  will  remain  valid  during,  the  course  of  later  design  trade  studies 
at  lower  levels. 
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Block  2,1  Techniques  and  Criteria.  A  first  step  in  this  task  is  to  provide 
working  tools  for  the  analysis  activities.  Techniques  anJ  criteria  to  bo 
employed  in  conducting,  the  analyses  should  he  established  at  the  outset  in 
such,  areas  as  the  following: 

a.  Analvsis  techniques  for  assessing  design  alternatives,  includine  format 
and  content  of  trade  studv  summaries. 

b.  Functional  and  design  requirements  for  specific  trade  studies. 

c.  Established  constraints- -e.g. ,  with  respect  to  facilities,  power,  envir¬ 
onment,  communications,  manpower. 

d.  Evaluation  criteria  with  respect  to  critical  design  objectives  (loads, 
timing),  secondary  characteristics  of  eouipment  (the  "  ili’ies"i,  and 
computer  programming  feasibility  factors. 

Block  2.2  Identify  Candidate  Alternatives.  This  activity  involves  the  exer¬ 
cise  of  engineering/data  processing  judgment  based  on  knowledge  of  hardware 
and  software  design  approaches  that  are  pertinent  to  the  system.  It  is 
important  that  analysts  be  aware  of  the  range  of  applicable  technologv  during 
the  time  frame  of  the  system  program,  able  to  identify  the  areas  in  which 
significant  questions  exist,  and  prepared  to  assess  candidate  solutions  objec¬ 
tively.  The  activity  consists  of  constructing  an  approach  to  the  "system 
architecture"  and,  at  this  step,  identifying  alternatives- -involving  computer 
hardware,  consoles/terainals ,  communications,  and/or  software- -which  merit 
further  systematic  comparison  with  respect  to  performance  and  factors  of 
feasibility.  As  the  task  progresses,  additional  or  related  alternatives  mav 
be  identified.  However,  the  analysis  as  a  whole  will  tend  to  be  fruitful  to 
the  degree  that  the  "right  questions"  are  formulated  at  the  outset. 

Block  2.3  Perform  Trade  Studies.  A  trade  study  consists  of  comparing  two  or 
more  candidate  designs  with  resnect  to  all  of  the  characteristics  which  arc 


important  to  the  intended  application.  Characteristics  to  be  considered 
include  not  only  the  identified  performance  requirements  but  also  factors  of 
cost,  availability  and/or  development  times,  operability,  maintainability, 
growth  potential,  safety,  impact  on  interfacing  or  support  elements  of  the 
system,  ,md  flexibility  with  respect  to  lower-level  design  solutions.  Occa¬ 
sionally,  certain  performance  aspects  may  be  subject  to  analysis  through 
simulations  or  mathematical  modeling.  Generally,  however,  the  analysis  con¬ 
sists  basically  of  examining  the  advantage?  and  disadvantages  of  each  candidate, 
rating  the  candidates  with  respect  to  each  relevant  characteristic  (including 
experience i ,  and  arriving  at  an  overall  assessment  based  on  the  complete  set 
of  comparisons. 

Flock  2.4  Prepare  Trade  Study  Reports.  Each  study  performed  in  the  preceding 
step  should  be  documented,  preferably  in  a  summary  form  similar  to  the  Design 
Trade  study  Report  described  in  PI -S- 3606.  Backup  data  should  be  included 
where  indicated  to  clarify  the  selection  of  alternatives,  evaluation  criteria, 
and  identified  questions  or  points  of  importance  to  be  further  investigated 
arid  reported  by  competing  contractors  during  the  validation  phase. 

TASK  >;  -  T NTiiGRATF  AMP  DOOIMENT  SYSTEM  REQUIREMENTS 

The  function  of  this  task  is  to  analyze  information  available  from  pre¬ 
ceding  studies  and  document  system  requirements  in  forms  which  will  be  directly 
useful  in  preparing  the  system  specification  and  associated  program  plans. 
Products  should  consist  of  (a)  an  organized  collection  of  system  technical  data 
and  ifi  a  report  or  scries  of  reports  containing  summaries  of  the  studies 
accomp] i shed ,  inputs  to  program  planning  documents,  and  comprehensive  recom¬ 
mendations  for  content  of  the  initial  system  specification. 

block  ~.l  System  Requirements  Descriptions.  This  step  consists  of  compiling 
organized  descriptions  of  information  and  requirements  to  be  covered  in  Section 
.'  oi"  the  system  specification.  It  involves  reviewing  information  derived  from 
preceding  tasks,  assessing  it  for  completeness,  and  augmenting  it  fcv  further 
anal  vs  is  as  necessary  to  provide  recommendations  covering  (a1  functional, 
per fcrmnnc'.  .  interface,  and  design  requirements  for  the  system  as  a  whole 


and  ','bl  allocations  of  the  requirements  to  firmly- identified  system  segments. 
Descriptions  in  the  significant  areas  listed  below  should  be  supported  by 
functional  flows,  schematic  block  diagrams,  and  other  svstem  engineering 
documentation  relevant  to  each  area: 

a.  Svstem  definition.  Descriptive  material  defining  the  system  as  a  whole 
should  be  provided,  covering  mission  objectives  and  constraints,  integra¬ 
tion  with  other  systems/capabilities,  operational  and  maintenance  concepts, 
characteristics  of  the  threat,  and  other  aspects  of  the  mission  affecting 
design  requirements  for  the  system. 

b.  Interfaces  with  other  systems.  For  an  electronic  svstem,  inter-svstem 
interfaces  are  matters  of  communications,  relating  to  both  fit  character¬ 
istics  of  automatic  data  and/or  voice  communications  media  (hardware/soft  - 
ware)  and  (2)  messages,  to  be  outnut  and  received  by  the  given  svstem. 

All  of  those  must  be  identified  at  this  stage  and  also  defined,  at  least 
in  functional  terms,  at  levels  sufficient  to  delimit  their  scope  and 
nature.  However,  a  considerable  portion  of  this  effort  is  likely  to  be 
spent  in  searching,  compiling,  and  organizing  data  (or  references  to 
available  sources)  in  the  form  of  detailed  definitions  which  alreadv  exist 
for  interfaces  with  external  systems  and  organizations- -often  at  the  level 
of  message  tvpes,  formats/contents,  frequencies,  and  volumes,  together 
with  known  characteristics  of  the  communications  links.  Those  constitute 
predetermined  constraints  for  the  new  or  modified  system  which  should  be 
identified  comprehensively  in  advance  and  made  visible  in  the  initial 
system  specification. 

c.  Command  organization.  The  command  organization  should  be  described  in 
terms  of  levels  of  command,  mission  responsibilities  of  identified  orga¬ 
nizational  elements,  and  functions  to  be  performed  by  those  elements  at 
specified  operating  locations.  It  should  include  a  preliminary  estimate 
of  types  and  numbers  of  personnel  required  for  system  operation  and  sip- 
port,  taking  into  account  the  projected  locations,  normal  and  emergenev 
operating  modes,  and  planned  dutv  cycles. 
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Svstem  performance.  This  description  should  include  coverage  of:  iden¬ 
tified  modes  and  phases  of  svstem  operation;  performance  reouirements  for 
the  svstem  as  a  whole;  and  performance  requirements  for  identified  system 
functions  and  subfunctions.  Performance  requirements  for  the  system  as  a 
whole  normally  relate  to  total  system  capacities  and/or  response  times- - 
e .  e .  ,  total  capacity  for  handling  target  tracks  or  simultaneous  intercepts; 
minimum  times  to  accomplish  threat  identification  and  warning  or  other 
action,  Descriptions  of  information  processing  functions  should  emphasize 
coverage  of  operational  and  support  functions  at  the  higher  levels--i.e. , 
those  identified  in  first-  and  second-level  functional  flow  diagram? - -but 
should  also  extend  to  lower  levels  to  the  degree  indicated  in  each  area 
by  verified  operational  needs  or  desum  constraints.  Each  function/- ab- 
Hinct ion  is  described  in  terms  of  identified  function  inputs,  outputs,  and 
processing  onerations,  together  with  associated  performance  requirements. 

At  this  stage,  a  large  body  of  detailed  data  should  exist  pertaining  to 
the  inputs  and  outputs,  in  particular,  organized  in  a  form  that  can  be 
referenced  here  and  made  available  for  later  uses.  If  the  system  involves 
a  large  data  base,  the  description  should  include  identification  of  the 
data  categories  and  tvpes,  estimated  sizes  of  files,  references  to  exist¬ 
in'.'  data  definitions,  and  requirements/responsibilities  for  data  collection 
;md  maintenance. 

Allocations  to  svstem  segments.  A  significant  Part  of  the  final  report 
should  he  devoted  to  the  grouping  of  performance ,  design,  and  interface 
requirements  into  system  segments.  The  segments  are  identified  by  titles 
and  defined,  basically,  bv  their  allocated  functions  and  requirements. 

Ml  functions  and  performance  requi rements  (see  d  above)  should  be  accounted 
for,  including  total  svstem  requirements  which  are  apportioned  between  two 
or  more  segments.  At  the  performance  level,  allocations  should  be  supported 
bv  schematic  biock  diagrams  ( first -level  I  in  which  functions  assigned  to  the 
se>rments  are  traceable  to  the  system  functional  flows  and  the  nature  of 
functional  interfaces  is  clearlv  identified.  Interface  reouirements  imposed 
on  each  segment  include  both  functional  interfaces  that  are  identified  and 
defined  with  other  segments  and  external  svstem  interfaces,  as  allocated. 
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The  primary  function?  being  allocated  are  ones  which  will  he-  performed 
through-  the  combined  operation  of  command  personnel  and  computer  n roc ram'- , 
operating  in  the  context  of  general -purpose  digital  comnut ing  equipment, 
display/manual  innut  devices ,  and  communications  links.  Ana  1  vse?  jterinm! 
during  preceding  tasks  will  have  extended  the  system  segment  allocat ions  to 
the  point  of  identifying  further  reouirements  and  constraints  for  segment 
design  with  resnect  to  those  elements.  The  description  provided  here 
should  include  a  full  account  of  those  extended  results,  toeetnei  with 
recommendations  for  the  levels  of  design  reouirements  to  be  imposed  on  each 
segment.  Recommended  and  limiting  characteristics  should  be  identified  in 
such  areas  as  the  following: 

--General  logical  and  physical  equipment  configuration  and  geographic 
locations . 

--Estimated  numbers  and  processing  characteristics  of  computers- -speeds , 
capacities,  word  structure,  or  other  design  constraints. 

--Estimated  numbers,  types,  and  capacities  of  peripheral  devices  and 
requirements  for  special  svnthetic  signal /message  generating  or  inter- 
fact  equipment. 

--Numbers,  capacities,  and  tvpes  of  operator  consoles,  terminals,  or 
special  simulation  consoles,  together  with  innut/control  and  disnlav 
reouirements;  requirements  for  special  displays  fe.g. ,  large  wall)  or 
hardcopy  printers. 


-  -  Recommended  structure  and  characteristics  of  mission/operational  and 
support  computer  nrocrar.-.--e.e.  ,  language  forms,  data  base  management , 
operating  svstem,  si mul at ion/dnta  reduction,  maintenance/diagnostics. 
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Block  Inputs  to  Program  PI, 'ins.  I>uring  the  course  of  the  tiiree  system 

engineering  tasks  outlined  above,  the  Program  Office  has  also  been  responsible 
for  preparing,  coordinating,  and  integrating  appropriate  planning  documents 
to  suppor*  the  milestone  I  decision.  The  Program  Management  Plan  fPMPj 
includes  a  prominent  section  (Section  4,  System  Engineering  and  Configuration 
Management  1  which  should  be  based  on  information  derived  primarilv  from  the 
technical  effort.  Other  sections  of  the  PMP  aiid  other  plans  are  the  primary 
respcnsitd l ity  of  participating  commands  and  such  other  elements  of  the  PC 
as  procurement,  program  control,  and  logistic  support.  However,  most  of  those 
other  plans  depend  heavily  on  inputs  from  the  technical  program  to  be  accurate 
and  adequate.  Hence,  in  parallel  and  integrated  with  the  conceptual  phase 
system  engineering  analysis,  significant  engineering  management  efforts  should 
nave  been  accomplished  to  support  the  development  of  planning  information  in 
such  areas  as : 

--Program  Costs 
--Master  Program  Schedule 
--Statement  of  Work 

- -Prel  uninary  Work  Breakdown  Structure 
- -Iteterminat ion  and  Findings  ('PtF') 

-Advanced  Procurement  Flan 
-Source  Selection  Plan 

-  -  Real  Property  f acil i t ies  Plan 

-  Test  and.  I  valuation  Master  Plan  (TEMPI 
--integrated  Logistics  Support  Plan 

- -Computer  ke sources  Integrated  Support  Plan  (CRISP) 

-system  Operational  Concept 

Preparation  of  the  Specification 

Tilt  svsterr  spec;  f  i  eat  ion  should*  be  prepared  before  the  end  of  the  concert - 
tu.il  *'i.n-e,  initial  lv  in  draft  form,  for  review  and  coordination  hv  partici¬ 
pating  command.  - .  !  ol lowin'*  coord inat  ion,  it  is  submitted  to  higher 


headquarters  as  a  part  of  the  documentation  pack  a  re  required  fni  evaluations 
leading  tc  the  milestone  T  decision. 

The  preparation  process  involves  translating  the  technical  information 
described  above  into  careful lv-formulated  statements  of  sister,  requirement •- 
which  complv  with  format /content  instructions  of  Mil  -STIMW,  Appendix  i, 
observing  supplementary  instructions  provided  in  Appendix  I: I  of  MIL  ST-  is.- 
fUSAF  •  to  the  degree  that  those  apt>l'-  to  the  liven  p  roc  ran  at  tins  tta,i  : 

a.  The  decision  may  he  made  to  write  the  specification  in  the  for”  of  one- 
general  volume  and  a  separate  volume  for  each  system  segment,  in  this 
case,  the  format  should  follow  instructions  in  paragraph  3'd . I  cf  'dTi-.\TT- 
483. 

b.  Content  instructions  provided  in  Mil.- STDs  49°  and  if,?  ;;>ara.  .30.3'  an.- 
for  the  fully-completed  specification.  At  this  stage,  significant  deci¬ 
sions  to  he  made  relate  tc  the  appropriate  degrees  of  incomplete™  ss  at 
which  requirements  should  be  specified  in  certain  areas.  In  general, 
complete  and  definitive  requirements  should  be  specified  in  most  areas 
which  pertain  to  system  definition,  design  standards,  and  other  charac¬ 
teristics  of  tne  system  ar  a  whole  fi.e.,  covered  in  paragraphs  through 
".(■  of  the  specification'.  However,  reouirements  in  paragraph  3."  .Func¬ 
tional  Area  Characteristics!  and  3.1.4  'System  Diagrams',  in  particular, 
must  be  carefullv  formulated  to  (’ll  include  all  performance/ mt er face 
requirements  and  design  constraints  wiiich  have  been  firmly  established 

and  verified  at  this  time,  but  (2;  permit  maximum  latitude  for  further 
analysis  and  hardware/sc ftware  design  solutions  hv  competing  sourci  > 
during  the  validation  phase. 


Conn' let int;  the  System  Specification  -  Validation  Phase 


‘An  or  goals  of  the  validation  nhase  are  to  expand  and  refine  the  system 
specification.  establish  firm  performance  specifications  for  configuration  item.? 
which  meet  svstem  requirements,  and  promote  the  accomplishment  of  comprehensive 
contractor  planning  for  system  development  which  is  realistically  consistent 
v;t:;  reduced  program  risks.* 

The  technical  studies  of  principal  interest  to  the  process  of  expanding 
nnu  completing  the  system  specification  durine  a  validation  phase  are  those  con¬ 
ducted  by  contractors.  However,  the  responsible  Program  Office  must  Plan  and 
manage  this  phase  as  a  whole  to  encompass  a  total  of  three  successive  time 
period'- : 


- - -  ■  —  -  ■  - - 

1 

1 

PLANNIM* 

IWEMFNTATION 

EVALUATION 

•  ?r<  t>rarr.  PIp.t; 

•  f'erf^rri  Ana)  v«;  i  s/jtps  lgn  StnAiri 

•  rvaJuale  Contractor  Prndui  r « 

•  I'ifp.it*'  K  pft 

•  Evpanil  f’  V t  r*r.  Sp^r  1  f  1  r  a  *  }  or. 

•  Update  ^vstcr  Sp"c t f 1  n» t lor 

•  1  n,  •  \,nir  'p; 

•  fropar**  T  t  pt*  f’erf  .-rmanf  «• 

•  UpHafr.  Propraf  Plan* 

•  /  v.  it  *  r onr  r  a" :  < 

•  Prcpar**  plnnc  ^  Schpdolpc 

_ 

•  T'rpp*rr  for  Milestone  IT 

a.  !  Imi'.int  s?  accnmpi  l.shed  during  an  initial  period  following  the  milestone  1 
-.v.  i-  .on.  Sumi  ficant  effort  is  required  to  prepare  program  planning  docu¬ 
ment  •- .  issue  the  Request  for  Proposal  'RFP)  package,  select  sources,  and 
award  contract  s. 

" .  Implement  at  ion  is  accomplished  bv  the  selected  contractor ( s ! . 

[•.valuation  coir  ists  of  assessing  the  results  of  contractor  efforts,  updating 
an,  expand ine  n roe ram  Plans,  and  prenarine  documentation  required  for  the 
"  :  i "  tom-  i  I  dec  i  v  '.on . 

l  f  ied  .!  i ion-'  of  maior  and  suits  idiarv  obiect  ives  for  the  validation, 
•■inis,  .'in •  provided  in  At  SC!'  SOC-o  (dn, inter  5i  and:  APSCP  80u-<  i Chanter  »•  . 

-e;  .its.-  '.  '  herein  for  a  lurther  discussion  of  risks  encountered  in  electronic 
■•■'■-ten:  nrcv’i  rims . 
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2.5.]  Manning  and  Preparation 

Miring  this  first  period,  the  initial  system  specification  prepared  during 
the  conceptual  phase  is  reviewed  and  revised  as  necessary  to  reflect  additional 
information  or  changes  resulting  from  the  milestone  I  evaluations  and  decision: 
The  svstem  specification  will  begin  during  the  next  period  to  perform  its  Mg- 
nificant  role  as  the  primary  document  governing  technical  ohiectires  for  the 
svs'em  program..  After  being  established  at  tins  time  h>  the  PO';  cont'igura:  ioi: 
control  board  iC.CE'  as  the  functional  baseline,  no  further  changes  mav  occur 
except  through  formal  processing  and  approval  ef  engineering  change  proposals 
fF.CPs ! .  Expansions  to  he  provided  later  by  the  validation  phase  contractors 
are  included  among  "changes”  which  require  that  forma]  processing.  However, 
effort  should  he  made  at  this  time  to  minim. ice  tne  likelihood  that  those  will 
need  to  include  changes  to  the  basic  requirements:  it  is  to  he  honed  that  thev 
can  be  limited  tc  expansions  involving  further  definition  of  system  design:  '  it." 
respect  to  hardware /software  configurations  within  the  svstem  segments. 

Evaluation,  of  the  system  specification  for  adequaev  should  be  supported 
activelv  by  the  operational  command,  as  well  as  by  such  other  available  exper¬ 
tise  that  can  be  brought  to  bear  bv  the  Program  Office,  prior  to  issuing  the 
validation  phase  RFP.  Expressed  simply,  the  important  judgment  to  be  readied 
is  whether  the  projected  system,  if  further  defined  and  built  to  meet  the 
requirements  exactly  as  stated,  will  indeed  meet  needs  of  the  operational 
mission.  That  judgment  is  necessarily  an  estimate;  and  it  happens  to  be  one 
which  has  proved,  over  the  history  of  system  programs,  to  be  subject  to  a  sys¬ 
tematic  bias:  Further  work  as  the  program  moves  downstream  inevi tatty  results 
f»:  a  better  u'ider standing  ef  technical ,  cost,  and  time  implications  ef  the 
rerr'  rements  as  originally  stated,  and  in  discoveries  of  ne v  rrcu' reman \s  < .-r 
vrr-'iously  ider.t  fied — always,  resulting  in  expansion.  That  phenomenon  has 
long  been  the  chronic  and  major  cause  of  cost/schedule  overruns  and  program 
failures.  To  expect  that  its  effects  can  be  eliminated  completely  is  unreal¬ 
istic.  But  it  represents  the  principal,  known  source  of  risk  in  electronic 
svstem  programs  which  a  validation  phase,  if  properly  planned  and  managed,  can 
reduce  tc.  an  acceptable  Level. 

?9 


Related  preparation?  to  he  accomplished  during  this  period  include  the 
cl  i  owing  act  i  vi  t  ies : 

Ihxiating.  coordinating,  and  issuing  the  Program  Management  Plan  fPMP) . 

"reparation  and  release  or  the  Ri-T1  package  to  potential  contractors . * 

Contractor  preparation  of  validation  rhase  proposals. 

.■•wan;  of  validation  phase  contracts,  based  on  proposal  evaluations  and 
source  selection  procedures. 


The  svst.eir  specification  is  included  in  the  RFP  as  a  Dart  of  the  statement 
:  rk  :?OV.": .  together  with  requirements  for  its  further  analysis  and  evran- 

tcr.  '->v  the  v.i!  i car  ion  phase  cent;  actors.  ienerallv,  the  candidate  contract.  ,' 
have  -ave^ttu  * f torts  in  studies  rf  the  program  prior  tc  receipt  of  the 
Fr:  hence,  since  they  must  also  perform)  further  analyses  during  the  process 
f  preparing  proposals,  the  successful  candidates  shoulu  have  accrued  a  sub- 
taut  is;  knowledge  of  the  progra;:  by  the  time  the  next  period  bee  in? . 

svs;»-iii  engineering  document  at  ion  incorporated  as  *' inr.  requirements  in  the 
sin'.  ;;vst  em  sr>ei  i  ficat  ion  -.para .  1.4'  will  normally  consist  only  of  selec 

c I  cud  ion-  o'  tie,  document  at  ion  generated  during  earlier  studies  ; see 
hove  .  However,  th"  ,v'.  sbeuld  prepare  a  list  of  documents  which  have  a 
;rcct  bearing  on  tiv.  system,  including  conceptual  phase  studies,  and  provide 
o:  ies  of  the  list  with  the  RH\ 


; i. : *  scrlr  t  .on  assumes  .  for  s.impl  icity,  that  the  s'  ster.  is  tc  tx-  procured 
.  '.ater.  during  lull  -scale  development,  through  a  '-ingle  prime  contractor, 
b.-mever.  it  may  lv  .1  viable  ont  ion  in  some  programs  to  use  associate  contrac- 
'  or:-  : p r  separate  ■■vstem  segments,  in  that  case,  the  system  specification 
'il:  n;e  ;■  been  prepared  in  the  form  of  one  general  volume  and  separate  vciume 
'V:  tne  segments :  and  competition,  during  validation,  would  be  r>v  competing 
•is.-.-i  "cvhnica!  activities  should  be  ha  icaii”  s  ir.il  nr  rr  the  diecree 

that  segment-  consisting  in  itself  of  separate  functional  areas  - -merits 

;  ■■arable  approach  to  Us  anal  -si'.;  and  design. 
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Implementation 


Descriptions  provided  below  of  technical  activities  performed  by  contrac¬ 
tors  during  this  period  follow  the  synoptic  outline  of  events  depicted  in 
Figure  1-5.  Activities  shown  in  the  figure  are  limited  to  those  leading 
direct lv  to  major  products  mentioned  earlier  relating  to  the  system  specifica¬ 
tion,  item  specifications,  and  program  plans.  It  is  conceivable  that  reasons 
could  exist  tc  require  a  prototype  ii.e.,  nartial  prototvne i  demonstration  as 
a  part  of  this  phase.  In  that  event,  there  would  be  additional  activities 
wh? :h  would  interact  with,  but  should  not  replace,  these  mainline  activities. 

This  phase  as  a  whole  is  described  below  as  consisting  of  three  successive 
stages:  fa-*  a  first  stage  devoted  to  meeting  technical  o:\iectives  reflected 
in  reauirements  for  the  System  Requirements  Review  fSRR);  a  second  stage  which 
terminates  with  successful  completion  of  the  System  Design  Review  f SDR ) ;  and 
a  final  neriod  during  which  contractors  complete  and  submit  all  products  for 
this  nhase  required  by  their  contracts. 

? .  5 . 2 . 1  System  Definition 

The  contractor's  efforts  at  this  initial  stage  should  be  devoted  to  expand¬ 
ing  the  system  engineering  studies  described  above  for  the  conceptual  phase 
fZ.4.1i.  The  technical  approaches  should  be  basically  similar;  however,  they 
are  now  guided  by  firm  decisions  reflected  in  the  initial  svstem  specification, 
and  by  known  requirements  (stated  in  the  SOW)  for  studies  in  specific  areas 
indicated  by  results  of  the  earlier  work.  Hence,  while  the  contractor  should 
study  and  understand  the  mission,  functional,  and  performance  analyses  accom¬ 
plished  previously  at  the  higher  levels,  he  should  not  be  required  to  iterate 
those.  The  major  emphasis  at  this  time  should  be  placed  on:  (a  >  expanding 
the  analysis  of  functions  to  lower  levels;  (b)  determining  design  requirements 
for  the  system  segments;  (c'  performing  trade  studies  to  evaluate  both  func¬ 
tional  and  design  solutions;  and  fdl  arriving  at  allocations  of  the  require¬ 
ments  to  identified  hardware  and  software  items  w'ithin  each  svstem  segment. 
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The  purpose  of  SPK  is  tc  review  and  evaluate  the  contractor’s  progress  in 
accomplishing  tnos-'  tasks,  as  they  contribute  to  specifving  functional  and 
physical  characteristics  of  the  system  as  a  whole.  As  indicated  in  Figure  2-5, 
the  last  step  mentioned  is  probably  the  most  visible  single  indicator  of  whether 
the  SRR  objectives  are  being  met.*  The  system  specification  will  not  be  full'' 
completed  until  all  items  can  be  identified  (in  paras.  3.1  and  3.1.4)  by  Cl 
number  or  equivalent,  approved  nomenclature,  and  specification  number.  The 
total  listing  will  identify  all  commercial  and  Government  inventory  as  well  as 
developmental  items,  and  all  items  required  for  support  as  well  as  for  opera¬ 
tional  functions  of  the  system.  Some  of  the  minor  items  need  not  be  precisely 
identified  until  later.  However,  the  list  should  be  complete  at  this  point  in 
the  program  with  respect  tc  all  items  upon  which  the  ensuing  validation  phase 
activities  are  dependent.  Those  include  both:  (a)  existing  items  (e.g.,  com¬ 
puters,  consoles,  and  major  items  of  support  software)  which  affect  the  content 
of  subsequent  studies  and  planning,  and  (b)  items  of  new  development  for  which 
development  specifications  are  to  be  prepared  during  the  next  stage. 

Evaluation  of  the  proposed  hardware/software  configuration  for  each  segment 
should  be  based  on  consistency  with  documented  design  requirements  derived  from 
the  functional  allocation  and  trade  studies,  and  on  compliance  with  management 
criteria  set  forth  in  such  sources  as  AFSCP  800-7  and  MIl-STP-483.  Those 
sources  recognize  that  the  item  selection  process  is  largely  a  matter  of  judg¬ 
ment,  involving  experience  and  awareness  of  the  relevant  technical  and  manage¬ 
ment  considerations.  However,  the  established  criteria  for  the  selection  of 
"configuration  items"  tend  to  apply  most  directly  to  items  of  new  development. 
Some  special  questions  encountered  in  dealing  with  mixtures  of  commercial  and 
developmental  elements,  which  have  been  characteristic  of  electronic  system 
programs  in  recent  years,  are  discussed  in  the  next  section  (see  3.2). 


*Although  referred  to  here  as  a  single  event,  SRRs  may  be  scheduled  on  succes¬ 
sive  calendar  dates  to  correspond  with  expected  progress  (a)  initially,  in 
defining  the  system  configuration  for  operational  functions  and  (b)  later,  in 
defining  derived  requirements  in  such  areas  as  logistic  support,  facilities, 
the  speci  pity  d  iscinlines  (reliability,  maintainability,  ...),  engineering 
integration,  and  test  planning. 
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2. 5. .1.2  Confieuration  Item  Definition 


The  identification  of  atoms  accomplished  in  the  preceding  stage  represents 
the  completion  of  design,  as  such,  at  the  level  to  be  specified  in  the  system 
specification .  Iterations,  refinements,  and  some  expansions  of  the  system 
specification  should  continue  to  occur  throughout  tne  remainder  of  this  phase. 
However,  the  principal  focus  of  the  system  engineering  effort  as  a  whole  shifts 
at  this  point  to  concern  with  requirements  for  the  individual  items.  In  gen¬ 
eral,  major  technical  activities  are  now  devoted  to  supplementing  the  system 
specification  with  item-level  specifications  and  other  documents  which  expand 
the  definitions  cf  requirements  allocated  among  the  identified  system  compo¬ 
nent?  --including  personnel  and  facilities  as  well  as  hardware  and  software. 

The  varied  and  interrelated  activities  which  should  be  completed- -or  nearly 
completed- -by  the  time  of  SDR  include  those  summarized  very  briefly  below: 

a.  Generation  of  the  allocated  baseline.  The  most  prominent  act ivitv  during 
this  stage  is  concerned  with  developing  or  acquiring  the  complete  set  of 
item  level  specifications  which  will  constitute  the  system  allocated  base¬ 
line  when  completed  and  approved.  The  allocated  baseline  encompasses  the 
total i tv  of  system  requirements  allocated  to  items  of  hardware,  software, 
and  facilities,  it  is  documented  in  the  form,  of  specifications  which  will 
be  placed  on  contract  during  the  next  phase  of  the  program  to  govern  the 
development  or  other  acquisition  of  those  items.  As  identified  in  the 
system  specification  (i.e.,  in  the  specification  tree.  para.  3.1.4) ,  those 
may  include  most  or  nearly  all  of  the  following  types  and  forms: 

(1 :  Computer  Program  Development  Specification  (Type  B5) .  By  and  large, 
most  of  the  operational  functions  of  an  electronic  system  are  allo¬ 
cated  to  computer  programs.  The  process  of  generating  a  B5  specifi¬ 
cation  involves  further  analysis  of  the  allocated  functions  to  much 
lower  levels  than  they  are  specified  in  the  system  specification.  In 
"erms  of  total  time,  manpower,  hulk  of  essential  detail,  and  direct 
significance  to  the  operational  mission,  this  task  should  normally 
account  for  most  of  the  system  engineering  effort  expended  during  the 
validation  phase  as  a  whole. 
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V  . 


(21  Hardware  Development  Soecifi cations.  Although  electronic  system 
programs  do  not  tvpicallv  include  the  development  of  maior  items  of 
new  aerospace  equipment,  there  are  norma] ]v  some  items  to  be  newly 
developed  for  undergo  maior  modification,  e.g.,  a  console  or  communi¬ 
cations  element)  which  require  the  preparation  of  development  speci¬ 
fications.  Depending  on  the  item  complexity  and  other  factors,  the 
specifications  prepared  at  this  time  will  be  Tvpe  El  (Prime  Ite- '> , 

B2  (Critical  Item],  or  B3  (Non-Complex  Item'. 

(3)  Facility  Specification  fTvpe  B4).  The  system  soecif icat ion  identi¬ 
fies  facilities  with  respect  to  intended  use,  general  characteristics, 
and  status- -i .e. ,  whether  existing,  to  be  modified,  or  to  be  newly 
constructed.  The  preparation  of  a  T}pe  34  specification  is  initiated 
at  this  time  for  facilities  requiring  new  construction  or  maior  modi¬ 
fications.  Requirements  are  derived  largely  as  a  part  of  the  on-going 
analyses  of  requirements  for  system  equipment  and  personnel. 

(4)  other  Specifications.  In  terms  of  numbers  alone,  most  of  the  speci¬ 
fications  to  be  preoared  or  acquired  at  this  time  are  likely  to  be 
for  existing  items  of  hardware  and  software.  Depending  on  sources  and 
other  factors,  these  will  include:  Tyne  C4 ,  for  items  already  in 
Government  inventory;  specifications  to  commercial  practice  f * TT !.  S-S34P0 
Form  2  or  Form  3);  or  product  function  specifications,  Tyne  Cla  or  C2a. 
Although  classed  as  "product  snec if icat ions",  these  should  general lv 

be  anproved  and  controlled  as  part  of  the  allocated  baseline  fo-1'  the 
reason  that  the}’  constitute  the  only  requirements  documentation  to 
govern  the  acquisition  of  the  items  during  full-scale  development. 

Personnel  and  training  requirements.  This  activity  consists  of  developing 
information  relating  to  numbers  and  tyoes  of  personnel  needed  for  field  and 
organizational  operations  and  maintenance,  and  to  projected  needs  for  indi¬ 
vidual  and  team  training.  Earlier  estimates  of  personnel  requirement?  arc 
refined  during  this  period  largely  on  the  basis  of  data  derived  from  the 
on-goinc  analyses  of  requirements  for  equipment  and  computer  program  CTs, 
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supplemented  by  additional  analvsis  normally  required  to  develop  the 
standard  qualitative  and  quantitative  personnel  requirements  information 
'QOPRI )  report.  Depending  on  the  system,  significant  additional  efforts 
may  be  involved  in  developing  requirements  for  capabilities  that  can  be 
used  bv  t tie  operational  command  to  perform  simulated  exercises  for  pur¬ 
poses  of  system  training  and  evaluation. 

c.  item- level  development  and  test  plans.  Technical  planning  for  the  devel¬ 
opment  of  nev.  Cls  and  CPCIs  should  be  accomplished  in  parallel  with  the 
svstem  engineering  analyses  being  Performed  to  develop  the  Tvpe  P  speci¬ 
fications.  This  activity  normally  involves  conducting  preliminary  studies 
of  hardware  or  software  design  for  each  item,  which  should  be  carried  out 
during  this  phase  in  .sufficient  depth  to  provide  a  basis  for  'll  evaluating 
the  impact  and  feasibility  of  detailed  performance  requirements  as  they  are 
formulated,  and  (2)  determining  schedules  and  resource?  needed  for  each 
item’s  development  during  the  next  phase.  Internal  test  planning  is 
included  in  the  development  plans.  Separate,  preliminary  plans  for  Cl  and 
CnCI  qualification  should  be  developed  concurrently  and  in  coordination 
with  test  requirements  being  documented  in  Section  4  of  the  B-tvpe  speci¬ 
fications  . 

d.  System  integration  and  test.  Significant  continuing  activities  at  the  sys¬ 
tem  level  are  concerned  with  requirements  and  plans  in  the  areas  of  system 
and  svstem  segment  interfaces,  site  installation  and  checkout,  and  system 
development  test  and  evaluation  (DTSPl .  Bv  the  end  of  this  phase,  func¬ 
tional  definitions  of  all  svstem  and  inter-segment  interfaces  should  be 
completed  and  incorporated  into  the  svstem  specification,  together  with  all 
definitions  at  lower  levels  which  exist  as  predetermined  constraints  fcf. 
2.4.1  above.  Mock  3.1b'. .  Following  the  completion  and  verification  of 
performance,  desivn,  and  interface  requirements  in  Section  .3,  Section  4 
must  be  completed  to  specify  methods  and  levels  of  PTSF  to  he  om loved  in 
verifying  that  t  hose  requirements  are  met.  As  a  part  of  these  activities . 
associated  pi  am  are  -prepared  for:  interface  control  during  the  develop¬ 
ment  Phase  : primarily  for  equipment  and  facilities  :  site  equipment  instal¬ 
lation;  and  -I’qo  I  Hat 
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The  SDR  is  conducted  before  this  stage  ends  to  review  requirements  of  the 
undated  system  snecification,  specifications  of  reouirements  allocated  to  con¬ 
figuration  items,  and  the  contractor’s  accomplishment  of  system  engineering 
management  objectives.  System  engineering  studies  should  have  been  performed 
as  required  by  the  SOK--and  by  the  nature  of  questions  encountered  during 
progress  of  the  work--,  either  separately  or  as  inherent  marts  of  the  activiti.es 
described  above. 

At  the  system  level,  the  emphasis  at  SDR  is  placed  on  adequate  coverage  and 
assessment  of  system/system  program  characteristics  in  such  areas  as  integrated 
logistic  support,  standardization,  growth  capabilities,  life  cycle  costs,  and 
other  special  topics  listed  in  Appendix  B  of  MIL-STD-1S21A,  as  applicable  to 
the  given  program.  Objectives  are  similar  to  those  cf  the  preceding  SRR ,  but 
with  attention  at  this  time  to  comprehensive  coverage,  completeness,  and  integ¬ 
rity  in  the  light  of  lower-level  studies  of  requirements  allocated  to  the  system, 
elements.  Information  required  in  final  font,  pertaining  to  the  specification 
tree  and  Cl  lists  fin  paras.  5.1.4  and  3."  or  the  system  specification;  should 
be  fully  complete  by  SDR,  including  specific  identifications  of  all  equipment 
and  computer  programs  required  for  support  as  well  as  for  mission  operations. 

At  the  item  Level,  a  significant  purpose  of  SDR  is  to  review  the  specifica¬ 
tions  proposed  to  constitute  the  system  allocated  baseline- -  for  iermat,  content, 
technical  integrity,  traceability  to  system  mission/ support  reouirements,  and 
correlation  of  requirements  across  the  full  set  of  items.  The  general  emphasis 
of  this  review  is  on  verifying  that  the  contractor  has,  in  fact,  success rul]\ 
translated  system  requirements  into  individuallv-defined  sets  of  rent:. cements 
for  the  system  hardware  and  software  elements.  Critical  requirements  to  be 
examined  for  data  processing  and  special  communications  equipment  items  relate 
to  speeds,  capacities,  compatibility  with  the  projected  nature  and  structure  of 
system  computer  programs,  and  secondary  characteristics  in  such  areas  as  opera¬ 
bility,  electromagnetic  compatibility,  reliabilitv,  and  naintainabil itv/availa- 
bilitv.  For  computer  programs,  particular  attention  is  tvnicallv  needed  to 
examining  fa)  system  engineering  documentation  generated  in  the  process  of 
deriving  requirements  for  the  mission/operational  CPCI ( s) - -together  with  related 
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requirements  for  operational  personnel  and  interfacing  equipment  characteris¬ 
tics  (e.g.,  detailed  operating  characteristics  and/or  layouts  of  displays  and 
manual  input  devices)--,  and  (b)  technical  integrity  and  completeness  of  the 
Type  B5  specifications  themselves.* 


2 . 5 . 5  Evaluation  and  Decision 

This  final  period  of  the  validation  phase  is  devoted  to  reviewing  and 
evaluating  contractor  products,  updating  program  planning  documents,  and 
accomplishing  related  actions  required  for  the  milestone  II  decision. 


Contractor  products  to  be  evaluated  consist  of  technical  and  planning  data 
items  delivered  against  the  validation  phase  CDRL.  The  total  package  of  data 
submitted  by  each  contractor  should  include  items  in  the  following  categories: 


--Updated/expanded  system  specification- -in  the  form  of  an  ECP  package, 
containing  specification  change  notices  (SCNs)  covering  exact  proposed 
page  changes  to  the  specification. 

--Allocated  baseline  documents- -the  full  set  of  development  specifications 
(or  their  equivalent;  see  2. 5. 2. 2, a  above)  for  hardware,  software,  and 
facilities  items. 


--System  engineering  documentation- -reports  of  functional  analyses, 
reouirements  allocations,  trade  studies,  human  factors  engineering 
studies,  program  risk  analyses,  computer  program  sizing  and  timing 
studies,  personnel  and  training  requirements,  et  al. 


*The  evaluation  of  B-tvpe  specifications  accomplished  at  SDR  is  preliminary , 
resulting  immediately  in  directions  to  the  contractor  for  corrections/improve¬ 
ments  to  be  incorporated  prior  to  their  submittal  at  the  end  of  this  period. 
Full  evaluation  of  the  specifications  as  a  basis  for  PO  authentication  (and 
baselining  for  subsequent  configuration  control)  is  accomplished  via  in-house 
specification  team  review  procedures  following  that  submittal.  A  further  dis¬ 
cussion  of  factors  to  be  considered  in  evaluating  the  Type  B5  specifications 
is  provided  in  another  guidebook  of  this  series  (see  ref. 18,  para.  2.1). 
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--Management  plans  for  full-scale  development --system  engineering  manage¬ 
ment  plan  (SEMP) ,  computer  program  development  plan  fCPDPj,  test  plans, 
equipment/site  installation  plan,  work  breakdown  structure,  and  others 
as  required  by  the  RFP  and/or  validation  phase  CDRL  ! for  a  "shopping 
list"  of  these  plans,  see  paragraph  5-18,  APSCP  800-5!. 

--Contractor  cost  information  and  recommended  inputs  tc  the  full-scale 
development  phase  SDK  and  CDRL. 

Those  items  should  be  evaluated  individually  against  requirements  estab¬ 
lished  for  each  item  in  the  contract  and/or  RFP.  The  system  specification  is 
evaluated  for  continued  adequacy  in  specifying  Air  Force  operational  needs  for 
the  system.  Each  contractor's  proposed  changes  should  consist,  primarily,  of 
expanded  definitions  of  the  system  segment  configuration-- i .e. ,  in  the  form  of 
Cl/CPCI  lists,  requirements  allocations  to  the  items,  and  schematic  block  dia¬ 
grams  depicting  functional  arrangements  of  the  hardware  and  software  assemblies 
Additionally,  the  contractor's  SCNs  should  normally  include  proposed  clarifica¬ 
tions  and  expansions  in  other  areas--e.g.  ,  design  and  construction  standards, 
inter-segment  interfaces,  and  test  requirements  (Section  4) --which  fully  reflec 
his  proposed  approach  to  system  hardware  and  software  implementation. 

However ,  the  important  overall  assessment  to  be  made  at  this  point  is 
whether  that  total  collection  of  technical,  management,  and  cost  information 
is  sufficiently  sound  and  realistic  to  warrant  progression  into  the  next  nhase 
of  the  system  program.  Assuming  that  the  system  specification  is  judged  to  be 
adequate  and  complete,  the  burden  of  that  overall  assessment  now  rests  on  deter 
mining  that  (a)  the  allocations  of  svstem  requirements  to  hardware  and  software 
elements  have  been  soundly  accomplished,  (b)  the  allocated  baseline  documents 
are  adequate,  both  individually  and  as  a  set,  to  govern  actual  acquisition  of 
the  system  elements,  and  (cl  the  contractor's  management  plans  and  cost  esti¬ 
mates  for  full-scale  development  represent,  in  fact,  serious  and  realistic 
planning  based  on  identified  needs  of  this  program. 


•V. 


ACTION  3. 


ISSUES  ANT  PROBLEM  AREAS 


The  system  specification  is  not  intended  to  be  a  "stand-alone"  document. 

As  prescribed  in  the  current  standards,  its  content  reflects  established  con¬ 
ventions  based  on  intended  functions  of  the  system  specification  in  relation  to 
the  many  other  documents  that  are  typical];-'  generated  and  used  in  the  course  of 
a  typical  system  program.  Generally,  specification  types  are  distinguish'd  from 
one  another- -and  from  such  other  documents  as  plans,  manuals,  reports,  etc.-- 
on  the  basis  of  such  factors  as  scope,  nature  of  technical  and/or  management 
content,  phasing,  sources,  and  intended  uses.  However,  the  structure  of  docu¬ 
ments  ir.  a  large  system  program  tends  to  be  sufficiently  complex  and  variable 
that  those  distinctions  are  not  always  obvious.  Purposes  of  the  discussion^ 
provided  in  this  section  are  to  summarize  intended  functions  of  the  system 
specification,  as  those  are  stated  or  implied  in  existing  standards,  and  to 
identify  a  few  problem  areas  which  have  proved  to  be  prominent  sources  of  diffi¬ 
culty  and/or  disagreement. 

3 . 1  Summary  of  System  Specification  Functions 

Traditionally,  specifications  are  documents  which  define  the  required  char¬ 
acteristics  of  items,  processes,  or  materials  to  be  developed  or  produced  and 
delivered  by  a  contractor.  The  specification  is  normally  referenced  in,  and 
functions  as  a  part  of,  a  contract  statement  of  work.  While  the  specification 
types,  forms,  and  uses  prescribed  in  current  military  standards  conform  gener- 
allv  to  traditional  Government  and  industry-  practices,  they  have  been  influenced 
significantly  by  considerations  derived  from  the  special  circumstances  of  system, 
acquisition  programs.  It  is  also  pertinent  that  the  standards  we  have  today-- 
i.e.,  those  contained  in  M1L-S-85490  and  MIL-STD-490--are  largely  based  on  Air 
rorce  systems  management  policies  that  were  in  effect  during  the  early  and 
mid-I 96f*s.  The  standards  have  not  changed;  but  some  questions  do  arise  as  a 
result  of  continuing,  substantial  changes  which  have  occurred  since  that  time 
in  the  policies  an.’  circumstances  of  system  acquisitions. 
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Tiie  direct  and  significant  implication  of  that  statement  is  that:  Contrac¬ 
tors  can  pc-  made  fullv  responsible  for  the  development  and  supply  of  end  items, 
ir.  accordance  with  item- level  specifications  which  are  made  a  part  of  their 
contracts,  ih. -  nor. traor.  >rs  are  not  oi  ~iaaT.ec.  t'  jc:  :nc~  tne  syszer  mectc  .Ai" 
~~roe  ~L .  A c  four ;  the  rcaponsibi liiy  for  comp  i :  anr.-c  v-i ir,  rhe  eyezerr.  spasifica- 
nr  c  jhr-Ze  rsn^ir.n  with  the  Air  borne  vrocurir.y  activity,  further  implica¬ 
tions  of  that  principle  are  amplified  in  tne  following  summaries  of  system-  vs. 
item- level  speci ficat ion  functions  during  the  course  of  a  svstem  program. 

'.i.j  Relations  of  iectinical  to  Management  Factors 


The  focal  products  of  contractors  to  be  specified,  managed,  and  accented 
during  a  s'-stem  program  consist  of  identified  items  of  hardware  and  software- - 
generally  referred  to  as  configuration  items.  A  few  of  the  established  rule? 
which  relate  to  miestions  at  hand  are  as  follows: 

a.  Although  special  provisions  are  made  for  some  hardware  components  ("criti¬ 
cal  items"!  which  may  be  specified  separately,  the  specification  "tree" 


*'  rom  il! .apt ei  I  of  thi  form*  r  AFSC  Manual  "5  1 ,  donfiimrat  ion  Management  During 
Acuuis  it  ion  Phase,  dated  1  .Tune  l'.H'Z.  The  uniform  specification  progr.v 
referred  t<  is  the  effort  which  led  to  tiic  structure  now  standardized  ir.  '!!;  - 
c-SA4'..u  and  'Ml  -"T"..- var-.  Prior  to  that  effort,  there  was  a  proliferation  of 
speci ficat ions  with  diverse  titles,  formats,  coverage,  and  uses. 


52 


consist?  basically  of  onlv  two  levels- -namelv:  f 1 >  the  system  level  and 
C t  the  iter  level.  Die  form  of  a  specification  tree  to  be  provided  in  the 
system  specification  (in  para.  1.1. -1  i  is  illustrated  m  Figure  3-1. 

That  specification  structure  must  be  capable  of  covering  the  acquisition 
of  all  hardware  and  software  needed  in  the  svstem.  However,  it  does  not 
have  xn  obvious,  one-to-one  correspondence  with  the  hierarch'.’  of  hardware' 
software  assemblies  which  is  typically  generated  as  a  result  of  engineering, 
analysis  and  design.  Figure  3-2  illustrates  a  (partial;  sample  of  the 
latter,  which  represents  the  immediate  teclmical  product  of  conceptual  and 
validation  phase  analyses  described  previously.  Essential  "correlation"  of 
that  breakdown  with  the  specification  tree  is  nevertheless  achieved  by 
virtue  of  the  facts  that: 

ll’  The  top  three  levels  represented  In  this  diagram  are  levels  of  assembiv 
to  be  defined  direct lv  in  the  svstem  specification. 

r2'\  Assemblies  at  the  fourth  level  nav  all  be  identified  and  specified  as 
separate  CIs  (except  that  the  Computer  Programs  block  showr.  in  this 
sample  would  be  likely  to  consist  of  separate  CPCIs  at  the  next  lower 
level! . 

r3)  Assemblies  at  lower  levels  may  be  specified  either  as  separate  CIs  or 
as  components  of  the  larger  CIs  into  which  they  assemble.  For  example, 
the  Power  Supply  (fifth  level)  could  be  identified  as  a  separate  Cl 
because  it  is  to  be  Government -furnished  or  procured  from  a  vendor. 

Thus,  the  Cl  concept  functions  to  define  a  contracting  level,  somewhat 
independent];-  of  the  technical /assembly  relationships  of  the  items  speci¬ 
fied.  That  is,  the  designation  of  a  "Cl"  applied  to  a  given  assembly  of 
hardware  or  software  components,  of  whatever  size  or  complexity,  defines  a 
level  of  management  as  between  the  procuring  activitv  and  contractor  which 
involves,  for  example:  one  specification,  one  set  of  technical  design 
reviews  and  configuration  audits,  one  test  (qualification)  program,  and 
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one  set  of  support  documentation.  It  is  the  level  of  delivers  and  accep¬ 
tance.  accountability,  and  provisioning  for  loeistic  support. 

In  the  framework  of  that  established  model,  assurance  that  requirements  for 
integrated  performance  of  assemblies  at  the  functional  area/system  segment 7 
system  levels  will  be  met  rests  heavily  on  provisions  for  controlling  inter¬ 
faces  among  the  CIs.  "Interface  control"  is  most  often  thought  of  as  a 
prominent  activit>  of  particinat ing  contractors,  carried  out  principal lv 
during  full-scale  development.  However,  the  only  real  control  contractors 
can  exercise  at  that  stage  is  over  their  in-process  designs  of  equipment 
items  at  the  product  level --to  meet  requirements  and  constraints  established 
in  their  contractual ,  ailocated-baseline  specifications .  Actually,  the  vr 
accepts  primary  responsibility  for  interface  compatibility  among  CIs  at  the 
time  the  Cl  performance  (allocated  baseline!  specifications  ate  approved  anc 
nlaced  on  full-scale  development  contracts.  The  assumption  is  that  measure; 
have  already  beep  taken--prior  to  and  during,  the  validation  Phase- -to  assure 
that  interface  requirements  were  systematically  and  comprehensively  identi 
fied,  analyzed,  allocated  to  CIs,  and  properly  incorporated  into  the  Cl 
specifications . 


3.1.2  Summary  of  System  Specification  Functions 

.As  indicated  above,  the  system  specification  is  a  document  which  governs, 
primarily,  the  PO  itself.  It  does  have  some  uses  as  a  contracting  instrument, 
however,  within  the  established  framework  of  system  acquisition  management  pro¬ 
cedures.  The  following  summary  includes  mention  of  those,  together  with  notec 
to  indicate  their  recognized  limitations. 

a.  Program  Requirements  Baseline.  The  system  specification  begins  to  function 
at  the  time  it  is  initially  prepared,  coordinated,  and  approved  by  HC  USAF 
as  a  part  of  the  1’0's  "charter"  for  pursuing  the  program.  It  defines  the 
technical  portion  of  the  program  requirements  baseline,  which  also  includes 
the  documented  operational  concent,  logistics  concept,  and  cost  estimates. 
Significant  changes  in  broad  objectives  defined  in  those  documents,  later 
in  the  program,  require  HO  USA!  review  and  approval. 
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h.  Func 1 1 cna 1  Baseline.  As  described  above  (2.5.1),  the  system  specification 
is  established  as  the  functional  baseline  for  formal  conf igurat ion  control 
bv  the  Program  Office  CCP  hy  the  time  it  is  issued  with  validation  phase 
RFPs.  Probably  its  major  single  function  in  the  life  of  the  program  is  to 
serve,  during  that  phase,  as  the  basis  for  program  planning  and  the  deriva¬ 
tion  of  lower-level  requirements  for  system  personnel,  hardware,  software, 
and  facilities.*  But,  since  it  continues  to  serve  that  and  other  signifi¬ 
cant  functions  identified  below,  it  is  systematically  controlled  thereafter 
and  maintained  tc  reflect  the  impact  of  all  approved  changes. 

c.  System  Test  and  Acceptance.  While  contractors  normally  provide  substantial 
support,  the  planning  and  conduct  of  system  DT$E  is  a  Program  Office  respon¬ 
sibility.  System  DTfjE  is  planned  against  requirements  stated  in  Section  4 
of  the  system  specification  and  conducted  to  verify  that  the  integrated 
collection  of  system  elements  will  in  fact  meet  the  performance/design  and 
interface  requirements  set  forth  in  Section  5.  Acceptance  of  the  system  by 
the  operational  command  is  based  principally  on  successful  accomplishment 
of  system  DT&L. 

d.  Total  System  Procurement.  The  assertion  has  been  made  that  the  Air  Force 
should  acquire  each  system  "as  an  entity"  from  a  single  contractor,  using 
the  system  specification  as  the  contractual  compliance  document.  Program 
Managers  do  have  the  flexibility  and  obligation  to  tailor  each  program 
according  to  its  needs;  and  there  are  understandable  motives  to  depart  from 
the  practice  of  procuring  solely  at  the  Cl  level  (see  3.2  herein).  However, 
the  system  specification  is  not  designed  for  that  application.  Some  of  the 
pertinent  considerations  are  mentioned  elsewhere  in  this  discussion.  Addi- 
t ionallv : 

■'li  The  accepted  acquisition  management  standards --throughout  such  areas  as 
configuration  management,  design  reviews,  test  programs,  and  acceptance 
--are  based,  hy  and  large,  on  the  established  differentiations  of 

*At  one  time  in  the  history  of  system  programs,  that  was  the  only  real  function 
of  a  system- level  specification.  After  that  initial  use,  it  was  often  simply 
replaced  by  the  other,  derived  documents. 


PC  and  contractor  responsibilities  for  the  system  as  a  v.nr  1  e  vs. 


figuration  fend',  items.  Current  standards  associated  with  AFP.  S 
series  procedures  provide  little  or  no  guidance  or  supnoTt  for  a  *cta 
system  procurement. 

2!  figure  .“-3  presents  a  summary  overview  of  system  specification  fine 
tions  in  eoveminc  both  the  on-going  system  program  anu  the  system 
itself  as  a  complex  end  product.  As  indicated,  elements  of  the 
resulting  system  are  acquired  individually  through  the  use  of  lower- 
level  specifications.  However,  some  of  those  essential  elements  of 
the  total  system  are  ones  which  a  prime  contractor  to  the  PC  cannot 
furnish,  and  which  the  PC  itself  can  control  only  within  limits  of  it 
designated  Air  Force  authority.  As  notable  examples: 

3:  The  PC  can  control  requirements  for  svstem  facilities  that  are  docu¬ 
mented  in  Type  P4  specifications.  Rut  actual  facilities  acquisition 
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igure  3-3.  Summary  of  System  Specification  Coverage  and  Functions. 


(military  construction  propram  I  must  he  accomplished  bv  the  Armv  Corps 
of  Engineers  or  Naval  Facilities  Command  (NAVFAC)  through  contracts 
administered  by  those  agencies. 

The  PO  can  also  control  the  development  and  dissemination  of  docu¬ 
ments  which  detail  requirements  for  the  selection  and  training  of 
system  personnel.  However:  manpower  allocations  must  be  made  by  HQ 
US\F;  and  personnel  are  actually  selected,  trained,  and  assigned  by 
ATC  and  the  operational  command.  --This  is  by  no  means  a  negligible 
consideration.  Deficiencies  m  trained  personnel  have  been  known  to 
cause  system  failures. 

e.  Item  Procurement.  The  svstem  specification  is  classed  as  a  "general"  speci¬ 
fication,  covering  characteristics  which  are  common  to  an  identified  class 
of  items  (m  this  case,  items  classed  as  parts  of  a  given  system),  whereas 
the  specification  for  a  single  item  is  classed  as  a  "detail"  specification. 
In  that  role,  it  does  normally  serve  as  a  supplement  to,  and/or  as  a  part 
of,  the  contractor's  procurement  specifications  for  end  items.  Thus,  in  the 
detail  specification  placed  on  contract  for  procurement  of  the  item,  some 
requirements  may  be  stated- -in  the  item  specification  itself--by  reference 
to  appropriate  paragraphs  of  the  system  specification.*  However,  the  PO 
must  take  care  tc  assure  that  the  referenced  requirements  are  identified 
specifically,  and  that  they  do  not  conflict  with  other  provisions  expressed 
directly  in  the  detail  specification.  Orders  of  precedence  listed  in  the 
SOIV  and/or  specifications  notwithstanding,  contractors  must  normally  observe 
lower- level  requirements  whenever  they  conflict  with  requirements  stated  at 
more  general  levels  or  in  higher-level  specifications. 

f.  Contractor  .Sendees,  The  process  bv  which  contractors  derive  program  plans 
and  lower- level  requirements  for  system  elements  from  the  initial  svstem 
specification  was  outlined  in  2.5.2  above.  The  system  specification 

*Fer  examples,  see  lai  Ml  I.-STD-4P0,  paragraph  20.3.3.(>  (specifying  "Safety"  for 
a  prime  equipment  item)  and  (h)  MIL- STD- 485,  Notice  2,  paragraph'  60.5.5.4 
(specifying  "Human  Performance"  for  a  CPC I i .  The  latter  happens  to  be  an 
unsound  example,  incidentally,  hut  for  reasons  unrelated  to  the  present  dis¬ 
cussion;  see  reference  IS,  paragraph  5.12. 
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functions  during  that  phase  as  a  compliance  document  in  the  sense  that  con¬ 
tractors  are  bound  to  be  consistent  with  its  requirements,  but  not  in  the 
sense- -normal  to  contract  specifications --that  the  contractors  must  delivcM 
a  set  of  validation  phase  products  which  meet  those  requirements  (name’'-, 
the  system  itself).  At  that  stage,  contractor  products  are  defined  direct! v 
in  the  SOK  and  CDRL  and  accepted  or  rejected  by  the  PO  on  the  basis  of  com¬ 
pliance  with  those  documents.  During  full-scale  development,  the  system: 
specification  is  normally  placed  on  contract,  together  with  item-level 
specifications  and  SOW  requirements  for  contractor  services  in  such  areas  as 
configuration  management,  interface  control,  system  installation/ integration , 
and  support  of  system  DT$E.  Again,  however:  while  contractors  are  now 
fully  responsible  for  meeting  requirements  of  it.em-level  specifications,  the 
system  specification  continues  to  function  primarily  as  a  reference  source 
of  criteria  against  which  to  judge  the  acceptability  of  their  services- - 
not  as  a  direct  definition  of  characteristics  to  be  achieved  by  their 
deliverable  products. 
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It  was  mentioned  earlier  that  the  principles  upon  which  the  established 
structure  and  roles  of  specifications  are  based  were  derived  in  the  context  of 
system  acauisition  management  policies  and  circumstances  which  existed  in  the 
earl\-  1960s .  Some  of  the  problems  encountered  in  recent  years  can  be  traced  to 
changes  in  the  latter  which  have  not  been  accompanied  by  corresponding  revisions 
or  clarifications  of  the  principles  and  their  applicability.  .Among  the  man}'  and 
varied  changes/trends,  two  are  noted  below  which  have  been  associated  prominent¬ 
ly  with  questions  about  functions  of  the  system  specification. 

PO  Manpower.  It  is  an  in-built  assumption  of  established  procedures  that 
the  P0  will  have  trained  and  experienced  personnel,  in  adequate  numbers  over  the 
range  of  significant  technical  and  support  management  disciplines,  to  "stay  on 
top"  of  a  system  program  throughout  its  duration.  However,  the  numbers  of 
trained  civilian  and  military  personnel  available  (and  authorized)  for  assign¬ 
ment  tc  I’O  positions  have  decreased  markedly  over  the  years.  With  limited 
resources,  pressures  have  increased  to  shift  a  greater  portion  of  the  total  bur¬ 
den  to  contractors.  POs  at  ESP  have  in  fact  taken  measures  along  that  line,  in 
two  forms:  fa')  of  acquiring  more  direct  support  to  the  PO  from  system  engineer¬ 
ing  contractors;  and  fb)  making  more  use  of  the  system  specification  instead 
of  allocated  baseline  specifications  as  the  primary  technical  requirements 
instrument  to  govern  full-scale  development.  Although  devices  of  necessity 
rather  than  choice,  both  of  those  have  been  reported  to  help  in  alleviating 
the  pressure.  As  indicated  in  the  preceding  discussion  of  system  specification 
functions  (5.1),  the  latter  represents  a  relatively  uncharted  approach  in  the 
light  of  established  principles  and  practice;  and  its  use  is  necessarily 
limited  to  something  less  than  the  total  system.  However,  additional  reasons 
which  suggest  that  it  should  perhaps  be  further  explored  are  discussed 
below. 

Existing  Items.  The  use  of  existing  commercial  and  Government - inventory 
items  has  shown  a  steady  increase,  as  a  result  of  both  current  policy  and 
increased  availability  of  general-purpose  components,  to  the  point  that  thev 


now  often  constitute  major  portions  of  a  total  electronic  system.  However, 

while  the  specification  structure  as  such  has  always  included  provisions  for 

those,  most  of  the  substantive  guidance  for  managing  system  contracts  applies  ! 

to  items  of  neu  development.  The  differences  in  indicated  (and  practicable 

management  procedures  are  sufficiently  extensive  that  care  has  been  taken  in 

some  programs  to  avoid  designating  the  commercial  elements  as  "configurat ion 

items",  largely  for  the  reasons  that:  their  commercial  spe  ifications  are 

typically  not  adequate  or  usable  for  configuration  control  at  either  the 

allocated  or  product  baseline  levels,  due  to  obstacles  posed  bv  considerations 

of  ownership  and  data  rights  as  well  as  content;  and  standard  procedures  for 

managing  technical  design  reviews,  qualification  testing,  and  configuration 

audits  are  not  applicable. 

The  fact  that  Type  P  specifications  are  not  written  for  commercial  items 
implies  that  special  attention  must  be  given  in  the  system  spec i ficat ion- •  i .e . 
in  the  initial  issue- -to  maintainability  and  related  support  requirements  to 
govern  the  selection  anu  acceptability  of  those  items.  The  nature  of  sue;, 
requirements  must  be  carefully  tailored  to  operational  and  support  concents  for 
each  system  with  respect  to  relevant  factors  of  geographic  location (si,  deploy¬ 
ment  ,  and  environment . 

5.2.1  Illustrative  Problem  Case 

figure  3-4  contains  a  diagram  based  on  the  arrangement  of  principal  equip¬ 
ment  items  proposed  by  one  contractor  to  meet  the  requirements  of  a  system 
segment  specification.  In  this  sample,  individual  items  identified  within  each 
of  the  four  sets  labeled  "functional  groups"  are  all  commercial,  including  two 
cr  three  requiring  some  degree  of  modification  for  this  intended  use.  Computer 
programs  (not  shown'!  are  associated  with  each  of  the  functional  groups, 
consisting  of  both  operational  and  support  items.  In  the  segment  as  a  whole, 
the  only  major  items  of  new  development  are  the  operational  CPCls. 

Referring  to  the  model  process  described  for  the  validation  phase  in  2.5 
above,  this  diagram  illustrates  a  situation  which  is  likely  to  exist  at  about 
the  time  of  SRR,  after  the  contractor  has  analyzed  segment-level  requirements, 
allocated  those  to  functional  areas,  and  identified  principal  items  of  hardware 
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I:i  pure  3-4.  Sample  Arrangement  of  Major  rquipmout  Items  in  a  System  Segment  . 
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and  software  within  each  functional  area.  The  preponderance  of  commercial  items 
is  clearly  in  line  with  objectives  expressed  in  the  SOW ;  and  it  does  have  the 
basic  advantage  that  significant  factors  of  performance  and  cost  are  relatively 
"proven"  as  compared  with  items  of  new  development.  At  the  same  time,  viewed 
in  the  light  of  accepted  acquisition  management  practices,  the  situation  poses 
to  the  PC  certain  novel  questions  and  problems  of  its  own: 

•  If  those  items  are  to  be  listed  in  the  expanded  system  specification 
and  their  commercial  "specifications"  accepted  and  approved,  the  PO 
must  perform  the  considerable  task  of  verifying  indeoendently  the  item 
selections,  performance  potentials,  and  interface  compatibilities  before 
incorporating  them  into  the  full-scale  development  contract. 

•  The  individual  items  shown  in  this  diagram- -computers ,  consoles/dis- 
nlavs,  and  related  equipment- -are  in  fact  properlv  identified  as 
"configuration  items",  to  the  degree  that  basic  criteria  for  Cl  identi¬ 
fication  and  selection  apply  at  all  to  this  total  segment  configuration. 
The  significant  consideration  is  that  each  is  a  level  of  assemble 
separately  manufactured  and  documented  as  such,  and  in  many  cases  by 
separate  original  suppliers/contractors . 

•  Nevertheless,  there  wall  be  little  or  no  eauipment  development  for  the 
PO  to  monitor  and  manage,  during  full-scale  development,  at  the  normal 
configuration  item  level.  Notably,  there  will  be  no  technical  design 
reviews  or  qualification  test  programs  for  the  commercial  items  as  a 
basis  for  their  audit  and  acceptance. 

•  When  contractors  are  responsible  for  CIs  of  new  development ,  they  share 
a  portion  of  the  total  program  risk.  But  one  net  result  of  this  case, 
carried  to  its  logical  conclusion,  is  that  essentially  all  of  the  risk 
(i.e.,  for  svstem  equipment!  is  shifted  to  the  PO,  since  new  develop¬ 
ment  is  now'  limited  to  complex  assemblies  above  the  level  of  CIs. 
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3.2.2  Proposed  Solutions 

The  situation  described  above  has  existed  in  several  programs,  although  with 
a  number  of  variations  in  relevant  circumstances.  As  indicated  earlier,  read; - 
made  solutions  are  not  prescribed  in  the  current  standards;  and  this  guidebook 
does  not  have  a  simple  solution  to  recommend.  A  PO  faced  with  those  problems  is 
largely  "on  its  own”- -although,  to  avoid  problems  that  could  be  even  worse,  any 
novel  approach  must  take  full  account  of  basic  principles  which  the  established 
standards  and  practice  do  reflect.  Some  considerations  are  summarized  below 
relating  to  each  of  three  approaches  that  have  been  tried  or  proposed  in  recent 
programs.  At  this  point  in  time,  all  of  these  need  further  study  to  clarify 
their  potentials  and  limitations  for  general  use. 

Two  of  the  three  solutions  referred  to  were  proposed  in  the  program  on 
which  the  diagram  shown  in  Figure  3-4  is  based.  The  other  (the  first  discussed 
below)  has  been  implemented  in  other  programs. 

a.  One  PO  has  adopted  the  approach  of  using  the  system  specification  as  the 
sole  contracting  instrument  to  govern  development  of  all  system  hardware 
and  software.  Although  subject  to  limitations  discussed  previously,  there 
are  indications  that  this  device  can  be  made  to  work  in  some  cases.  The 
cases  known  so  far  are  ones  in  which  the  system  happens  to  be  atypical ,  in 
that  it  does  consist  principally  of  one  large  prime  equipment  item  (a  "one- 
of-a-kind"  surveillance  radar).  The  purpose,  and  reported  real  result,  is 
to  reduce  demands  on  PO  manpower  by  placing  full  responsibility  onto  the 
system  contractor  for  all  management  at  the  Cl  level  during  full-scale 
development.  This  means  that  the  PO  has  correspondingly  less  control  at 
that  level  while  the  development  is  in  progress.  Implications  which  this 
PO  has  recognized  and  accepted  include  the  following: 

•  The  contract  specifies  that  normal  CT-level  requirements  (for  develop¬ 
mental  items)  are  to  be  observed,  in  a  normal  phasing  seauence,  in  such 
areas  as  development  specifications,  technical  design  reviews,  qualifi¬ 
cation  test  programs,  and  product  spec i ficat ions- -but ,  wholly  managed 
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and  controlled  by  the  prime  contractor  from  the  time  of  contract  award, 
through  successful  completion  of  system  DTSE.  The  system  testing  is 
also  managed/conducted  hy  the  contractor,  but  witnessed  and  approved/ 
accepted  hy  the  PO  (as  the  qualification  testing  would  normal It'  he  for 
a  CI1. 

•  Although  the  PO  may  act  as  an  observer  at  intermediate  Cl -level  events 
and  receive  information  copies  of  documents,  it  does  not  accent  or 
control  Cl -level  products  until  system  DTSE  is  completed.  At  that  end 
point  of  the  program,  the  PO  then  holds  a  physical  configuration  audit 
(PCA)  to  examine  and  accept  the  CIs,  their  specifications ,  and  other 
documentation. 

•  Configuration  management  procedures  are  adjusted  accordingly.  Through¬ 
out  the  period  of  initial  acquisition,  the  PC's  configuration  control 
is  confined  tc  the  functional  baseline  level .  The  prime  contractor  may 
report  to  the  PO  changes  to  CI/CPCI  specifications  which  he  has  base¬ 
lined  for  internal  control,  but  in  the  form  of  "record -only"  ECPs. 

b.  The  system  on  which  the  diagram  shown  in  Figure  3-<i  is  based  was  substan¬ 
tially  larger  and  more  complex  than  the  case  iust  described;  and  computer 
programs  were  a  more  prominent  part  of  the  total  acquisition.  The  plan  to 
manage  computer  programs  as  individual  CPCIs,  in  accordance  with  normal 
practice,  was  not  in  question.  With  respect  to  equipment,  however,  the 
questions  and  problems  outlined  in  3.2.1  above  led  members  of  the  PO  to 
search  for  an  alternative  approach.  Of  two  alternatives  proposed,  the  one 
adopted  fin  some  haste)  was  later  reported  by  participants  to  have  created 
more  problems  than  it  solved.  That  concept  is  outlined  as  follows: 

•  Each  of  the  complete  assemblies  illustrated  as  a  "functional  group" 
in  Figure  3-4  was  designated  as  a  prime  item  of  new  development. 
Equipment  CIs  identified  hy  specific  numbers  and  nomenclature  in  the 
system  (segment!  specification  tree  and  Cl  list  were  confined  to  those 
prime  items. 
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•  The  segment  contractor  was  required  to  prepare  a  Type  HI  specification 
for  each  of  the  functional  groups,  to  be  followed  later  by  a  Type  Clh 
(product  fabrication)  specification.  Following  acceptance,  they  would 
become  items  in  the  Air  Force  inventor'.-  at  that  level,  identified  as 
item?  manufactured  by  the  PC's  segment  contractor. 

•  Itevelopment  ana  test  plans  for  full-scale  development  provided  fcr 
design  reviews,  qualification  testing,  and  configuration  audits  at  the 
functional  group  (prime  item)  level. 

Some  of  the  problems  encountered  in  the  course  of  implementing  that  plan 
resulted  from  difficulties  experienced  by  the  contractor  in  preparing  the 
specifications,  particularly  at  the  product  fabrication  level.  Guidelines 
for  handling  the  commercial  items  ('now  identified  as  commercial  components- 
were  never  clearlv  formulated;  and  they  proved  to  be  matters  of  disagree¬ 
ment  with  respect  to  a  range  of  questions  having  to  do  with  the  use  of 
commercial  documentation,  quality/ forms  (and  even  availability)  of  engi¬ 
neerin'.:  drawings,  test  data  and  special  test  support  equipment  for  the 
commercial  components,  and  others.  One  significant  factor  which  tended  to 
exacerbate  problems  was  the  fact  that  the  requirement  for  the  contractor  to 
assume  those  respons lhi 1  it iec  did  not  emerge  until  after  the  contract  had 
started,  and  after  the  contractor  to  the  PO  had  already  negotiated  sub¬ 
contracts  and  purchase  agreements  with  original  equipment  manufacturers. 

c.  The  alternative  which  was  proposed  hut  discarded  in  favor  of  that  just 
described  is  not  known  to  nave  been  implemented  in  an  actual  program. 
However,  there  are  reasons  to  bel levc  it  would  have  neen  a  better  course 
to  follow.  The  concept  derived  in  part  from  the  fact  that  a  validation 
phase  had  not  neen  conducted;  and  there  was  early  evidence  that  the  system 
specif  lent  ion- -which  consisted  of  |one  general  volume  and  separate  volumes 
for  the  svstem  segment s - -had  suffered  from  an  absence  of  both  f 1 )  thorough 
system  engineer  mg  analysis  and  verification,  and  (2,  specific  expansions 
and  refinements  by  the  successful  segment  contractors  to  reflect  their 
intended  desien  approaches.  Based  primarily  on  discrepancies  in  the 
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latter  area,  combined  Kith  the  considerat ions  described  in  f.d.l  above  ,  thi  = 

proposal  outlined  the  following  principal  steps: 

•  The  contractor's  first  task  is  to  expand  the  system  segment  specifica¬ 
tion  to  define  functional  areas,  allocate  requirements  to  those,  an’ 
verify  consistency  with  the  segment  requirements  as  a  whole,  hi  thin 
each  functional  area,  requirements  are  further  allocated  to  computer 
programs  and  equipment.  However,  while  the  CPC Is  are  identified  speci¬ 
fically,  reciuirements  allocated  to  equipment  are  specified  for  the  group 
of  equipment  elements  in  each  functional  area  as  a  whole. 

•  Equipment  items  comprising  each  functional  group  are  identified  at  this 
time  by  generic  names  only.  Die  PO  neither  approves  their  selection 
nor  accepts  their  individual  (commercial)  specifications. 

•  Taking  into  account  the  fact  that  Type  B  specifications  will  not  exist 
to  provide  further  detailed  performance/design/ interface  requirements 
at  the  item  level,  the  definitions  of  requirements  provided  directly  it: 
the  system  segment  specification  itself  must  be  comnarable  in  scope  and 
level  to  the  content  of  a  Type  B1  specification  for  each  functional 
group  as  a  whole. 

•  Once  completed  and  approved  with  those  changes,  the  system  segment  speci¬ 
fication  is  then  placed  on  contract  to  govern  the  contractor's  develop¬ 
ment  of  those  functional  groups.  Development  and  test  Plans  are  prepared 
to  schedule  design  reviews,  testing,  and  configuration  audits  for  each 
functional  group.  Acceptance  of  individual  equipment  items  will  occur 
when  PCAs  arc  completed  successfully  for  the  functional  groups.  The 
system  segment  specification  is  then  updated  to  incorporate  specific 
identification  of  the  commercial  items.  After  that  time,  Air  Force- 
management  may  then  revert  to  the  item  level  for  purposes  of  logistic 
support  and  accountabil itw 
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5. 3  Program  Risks 


A  "program  risk"  is  a  factor  which  creates  a  likelihood  that  system  perfor¬ 
mance  or  supportability  objectives  may  not  be  achieved  within  the  acceptable 
range  of  projected  program  costs  and  schedules.  Since  it  is  characteristic  of 
system  programs  that  they  are  initiated  and  carried  out  to  develop  new  capabili¬ 
ties  which  take  advantage  of  the  latest  available  technology,  the  risks  which 
tend  to  receive  most  visibility  and  attention  are  those  of  a  technical  nature. 
Following  a  number  of  experiences  in  earlv  system  programs  which  attempted  to 
incorporate  scheduled  "technological  breakthroughs",*  it  has  long  been  a  policy 
within  the  DoD  not  to  permit  a  system  program  to  proceed  into  full-scale  engi¬ 
neering  development  until  assurance  exists  that  technical  risks  have  been 
minimi  red --meaning,  specifically,  that  subsequent  effort  must  be  a  matter  of 
straightforward  engineering  design  and  development  without  significant  depen¬ 
dence  on  further  invention  or  scientific  advancements.  Current  policies  also 
emphasize  earlv  identification  and  reduction  of  related  risks  associated  with 
the  system  operability  and  performance  in  its  intended  military  environment. 

Thus,  in  the  context  of  problems  encountered  during  full-scale  development 
and  later  phases  of  system  programs  with  embedded  computer  resources  in  recent 
rears,  there  has  been  a  widespread  tendency  to  assume  that  the  computer  re¬ 
sources,  especially  computer  programs,  constitute  areas  of  high  technical  risk. 
Hence,  steps  to  improve  the  software  base  of  technology  and  abilities  of  Program 
Offices  to  monitor  and  evaluate  the  technical  aspects  of  software  development 
have  been  prominent  among  lines  of  activity  taken  to  alleviate  the  problems. 
Tnose  efforts  are  clearlv  needed  and  appropriate,  to  a  degree.  However,  the 
risks  'known  or  unknown  at  the  timel  which  have  actually  materialized  into 
program  problems  or  failures  indicate  that  increased  attention  is  also  needed 
to  a  number  of  related,  other  factors  in  the  system  acquisition  program  as  a 
who 1 e . 


*\otah!e  examples  during  the  1950s  were  a  nuclear -powered  aircraft  (System  125.-V, 
and  the  outer-atmosphere  vehicle,  Dvnasoar. 
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Considering  the  complexity  of  large  system  programs,  failures  can  result 
from  deficiencies  in  any  one  or  more  of  many  areas.  To  he  successful,  the 
Program  Office  must  take  steps  to  assure  that  adequate  attention  is  oaid  to 
minimizing  risks  across  the  whole  snectrum  of  potential  pitfalls.  That  is  to 
say,  concentration  on  eliminating  anv  one  risk  factor,  however  significant,  is 
"necessary,  but  not  necessarily  sufficient".  However,  the  following  paragraphs 
discuss  a  few  risk  factors  associated  with  the  system  specification  which 
clearly  merit  far  more  concentrated  attention  than  thev  have  typicallv  been 
given. 

Based  on  many  surveys,  there  is  a  wealth  of  evidence  that  the  most  pervasive 
single,  technical  source  of  difficulties  in  system  programs  is  a  matter  of  defi¬ 
ciencies  in  the  amount  and  quality  of  system  engineering  effort  applied  during 
early  phases  to  develop,  document,  and  verify  adequate  definitions  of  require¬ 
ments.  This  deficiency  has  been  recognized  as  being  a  chronic  characteristic  of 
system  programs  in  general,  for  decades.  Awareness  of  its  effects  on  problems 
with  embedded  software  are  evidenced  in  such  comments  (by  system/ software  con¬ 
tractors!  as  the  following:* 

"...initial  requirements  were  not  critically  analyzed  and  verified  through 
a  formal  program  of  advanced  development  or  system  definition." 

"...lack  of  thorough  analysis  and  validation  of  requirements." 

"...many  technical,  cost,  and  schedule  problems  can  be  traced  to  inade- 
quately  defined  requirements." 

"Often  the  difference  between  success  or  failure  of  a  large  software 
project  lies  in  the  consistency  and  completeness  with  which  the  svstem 
requirements  have  been  specified..." 

"Much  more  effort  and  money  should  be  expended  on  the  preparation  of  good 
development  specifications...  The  Government  should  he  an  active  parti¬ 
cipant  in  the  technical  effort  loading  to  these  specifications." 


*Selected  quotations  drawn  from  the  DoD  Keapon  Systems  Software  Management 
Study  (ref.  1“  ) . 
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Iln^  kev  factor  accounts  for  the  emphasis  placed  above,  in  the  discus¬ 
sion  of  system  specification  development  (Section  2),  on  thorough  analysis  of 
system  requirements  during  the  conceptual  phase,  and  on  employment  of  the  vali¬ 
dation  phase  for  the  primary  purpose  of  completing/expanding  the  definitions  of 
system  and  software  requirements.  Those  objectives  are  consistent  with  current 
Air  Force/DoD  policies,  although  it  must  be  recognized  that  there  has  been  a 
dearth  of  guidance  or  support  for  their  implementation  in  the  manner  described, 
specifically  for  electronic  systems/computer  resources. 

One  possible  source  of  confusion  lies  in  the  label  "validation  ohase"  it¬ 
self,  which  tends  to  highlight  the  importance  of  such  activites  as  prototype 
demonstration  and  hardware  proofing.  Those  activites  are  indeed  emphasized 
within  the  DoP  for  major  defense  systems  in  general.  However,  it  is  also  clear 
that  that  emphasis  is  based  Primarily  on  reference  to  systems  in  which  the 
focal  developmental  efforts  and  technical  risks  are  associated  with  major  new 
prime  items  of  military  equipment -- such  as  supersonic  bombers,  cruise  missiles, 
ballistic/antiballistic  missiles,  nuclear  submarines,  or  tactical  aircraft.  The 
early  demonstration  principle  is  still  only  the  "means  to  an  end";  its  function 
is  to  support  the  mainline  objective  of  minimizing  urogram  risks  before  embark¬ 
ing  on  a  full-scale  development. 

Thus,  in  tailoring  his  program  according  to  its  needs,  it  is  incumbent  on 
the  electronic  system  Program  Manager  to  examine  the  applicability  of  those 
concepts  in  the  light  of  their  significance  to  his  actual  circumstances.  While 
there  may  be  exceptions,  the  overwhelming  weight  of  electronic  systems  experi¬ 
ence  dictates  that  in  most  cases  he  should — indeed,  must — conduct  a  validation 
phase,  but  will  rare  Ip  have  pood  reason  to  require  prototype  demonstration / 
hardware  proofinp  tasks  as  significant  parts  of  that  effort.  A  few  of  the 
relevant  considerations  are  summarized  below. 

a.  The  validation  phase  task  of  contractors  to  analyze  and  complete  the  system 
specification  represents  an  important  step  in  assuring  that  the  specifica¬ 
tion  is  a  sound  instrument.  F.ven  when  it  mav  have  had  the  benefit  of  good 
svstem  engineering  study  and  verification  during  the  conceptual  phase, 
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there  is  still  the  need  to  assure  that  its  requirements  are  compatible  with 
design  approaches  proposed  as  being  known  and  feasible  by  the  implementing 
contractor (s) . 

b.  Equally  important  in  promoting  the  PC's  confidence  that  contractor?  really 
understand  the  requirements  and  their  implications  are  the  results  of  asso¬ 
ciated  implementing  tasks  during  the  validation  phase- -of  identifying  item? 
of  hardware  and  software,  developing  item-level  performance  specifications, 
analyzing  development  and  support  requirements,  and  preparing  comprehensive 
plans  for  full-scale  development.  If  there  is  any  single  factor  that  car  be 
pointed  to  as  having  the  highest  priority  for  embedded  software,  specific;/!  1 '  , 
it  is  clearly  in  the  area  of  improved  development  specifications  for  opera 
tional  computer  programs. 

c.  Major  new  prime  items  of  equipment  are  not  normallv  developed  a?  part  of  an 
electronic  system  program.  Predominantly,  the  hardware  portions  of  the 
system  consist  of  digital 'computing  equipment,  communications  devices,  and 
consoles.  While  some  of  the  elements  may  be  newly -developed  for  the  giver 
program,  they  are  largely  commercial  off-the-shelf  or  consist  of  commercial 
components  arranged  in  a  tailored  configuration.  The  risks,  in  practice, 
tend  to  be  matters  of  proper  selection  and  assembly  of  those  items  such 
that  the  equipment  configuration  as  a  whole,  once  installed,  will  meet 
system  requirements  with  respect  to  types  of  data  processing,  speeds, 
capacities,  reliability,  and  supportabilitv. 

d.  The  prominent  items  of  new  development  for  most  electronic  systems  tend  to 
be  operational  (mission,  or  applications!  computer  programs.  There  are 
some  known  examples  in  which  certain  requirement?  stated  in  the  svster 
specification  have  raised  questions  of  technical  feasibility--and/or  tech¬ 
nical  competence  of  the  contractor--that  might  conceivably  be  resolved  or 
clarified  by  means  of  "software  proofing"  or  early  demonstration.  How¬ 
ever  : 

fl  I  More  often  than  not,  those  questions  should  normallv  have  been  exam¬ 
ined  and  resolved  before  completing  the  initial  svstom  specification. 
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Most  of  the  known  instances  (e.g.,  questionably-stringent  require¬ 
ments  for  data  security)  are  ones  which  imply  long-term  study,  and  are 
by  no  means  confined  to  software. 

(2)  Unless  there  happens  to  be  a  specific  objective  which  is  known  to  be 
exceptionally  important,  requirements  for  early  demonstration  as  part 
of  the  validation  phase  should  be  avoided.  In  the  competitive  environ¬ 
ment,  contractors  are  likely  to  channel  their  principal  and  best 
resources  into  that  activity;  and  the  other,  typically  higher  priority 
objectives  of  comprehensive  requirements  and  program  definition  will 
suffer  accordingly. 

(3)  Experience  clearly  indicates  that  the  PC's  most  urgent  source  of  con¬ 
cern,  normally,  is  whether  the  contractor  will  be  able  to  deliver  a 
total,  integrated  collection  of  the  system  software,  on  time  and  within 
estimated  costs,  which  really  meets  the  full  range  of  system  operational 
and  support  requirements.  No  case  has  yet  been  reported  of  a  system 
program  failure  caused  by  limitations  in  software  state-of-the-art  as 
such.  The  plethora  of  actual  problems  encountered -- i . e . ,  the  real-life 
risks  which  have  so  often  been  taken  and  lost --are  matters  of  inade¬ 
quate  requirements  definition,  planning,  and  management. 
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APPENDIX  A.  SYSTEM  SPECIFICATION  PREPARATION 


Most  of  the  content  of  this  appendix  is  drawn  from  a  system  specification 
preparation  guide  which  was  developed  at  AFSC's  Space  Division  fSD) .  The 
material  is  used  herein  with  the  permission  of  its  author,  Mr.  Ernest  hade  of 
The  Aerospace  Corporation,  to  whom  this  author  is  also  indebted  for  consultation 
in  adapting  it  for  this  use.  While  that  guide  emphasizes  requirements  which  are 
important  in  space  systems,  it  also  contains  information  which  is  both  generally 
useful  and  potentially  helpful  in  tailoring  the  MIL- STD-490  instructions  to 
other  classes  of  systems. 

The  principal  sources  of  general  requirements  for  preparing  a  system  speci¬ 
fication  are  Appendix  1  of  MIL- STD- 4 90  and  Appendix  III  of  MIL-STD-483  (US.AF) . 
The  instructions  contained  in  those  sources  set  forth  minimum  requirements  which 
are  written  at  a  very  general  level  tc  cover  all  classes  of  military  systems, 
and  to  serve  the  generally-useful  purpose  of  enforcing  a  base  of  standard 
practice.  However,  it  has  been  the  common  experience  that  a  substantial  amount 
of  additional  direction  and  guidance  is  needed  to  support  their  effective  use  in 
any  given  case. 

Basic  sections  of  this  guidebook  have  emphasized  the  fundamental  problem  of 
developing  and  verifying  an  adequate  foundation  of  requirements  data  to  provide 
the  essential  technical  content  of  a  good  system  specification.  Beyond  that, 
however,  the  process  of  translating  the  input  information  into  statements  of 
requirements  which  are  consistent  with  sound  specification  practices  is  a  sig¬ 
nificant  task  in  itself,  particularly  when  combined  with  typical  needs  to 
adjust  the  specification  format  and  emphasis  to  a  given  class  of  systems. 

A  committee  which  was  formed  to  investigate  problems  encountered  with  one 
system  specification  at  ESD  recommended  recently  that  a  new  pamphlet  be  devel¬ 
oped  as  c  .guide  to  the  specification  preparation  for  electronic  systems.  While 
that  topic  is  clearly  within  the  scope  of  subjects  which  deserve  coverage  in 
this  guidebook,  it  is  recognized  that  the  task  as  a  whole  demands  longer  time 
and  a  broader  base  of  resources  than  have  been  allocated  to  preparation  cf  this 


initial  issue.  Thus,  the  material  presented  below  is  limited  to  available  and 
relevant  information  which  may  prove  useful  as  a  starting  point  for  such  a 
longer-term  effort. 

Organization  and  Content 

To  avoid  the  use  of  a  dual  numbering  system,  paragraphs  in  the  remainder  of 
this  appendix  are  identified  by  the  section/paragraph  numbers  and  titles  speci¬ 
fied  for  the  system  specification  in  MIL-STD-490.  For  reference,  an  outline  of 
that  specification  structure  as  a  whole  is  reproduced  in  Figure  A-l.  (Note: 
the  coverage  provided  herein  extends  only  through  Section  5.) 

Guidance  material  presented  in  the  following  pages  is  organized  around 
successive,  relatively  short  groups  of  related  specification  paragraphs.  The 
material  associated  with  each  group  consists  of  information  derived  from  three 
sources:  ;a;  content  of  the  basic  SD  guide;  (b)  content  of  a  "model  specifica¬ 

tion”  which  was  printed  originally  as  an  appendix  to  the  SD  guide;  and  (c) 
comments  by  the  author  of  this  SAM  guidebook  on  significance  of  selected  topics 
to  electronic  svstems.  For  ease  of  ready  identification  by  readers,  those 
three  kinds  of  content  are  presented  in  different  type  style  or  format,  as 
illustrated  in  the  explanations  provided  below: 


Paragraph  x.x,  Basic  SD  Guidebook.  This  element,  taken  from  Mr.  Wade's  guide¬ 
book,  incorporates  instructions  extracted  from  MIL-STD-490  for  the  identified 
section  or  paragraph,  explains  the  instructions,  and  contains  additional  notes 
to  assist  specification  writers  to  interpret  their  applicability. 


x.x  Model  Specif ication.  This  element  is  also  drawn  from  the  SD  guide, 
It  provides  direct  illustrations  of  the  MIL-STD-490  format  and  "boiler¬ 
plate"  requirements  statements  for  each  section/paragraph,  to  which  each 
specification  writer  may  then  add  statements  peculiar  to  his  own  system 
program. 


ELECTRONIC  SYSTEMS  -  COMMENT.  This  element  does  not  always  appear.  When  it 
does,  it  consists  of  comments  on  selected  portions  of  the  system  specification 
which  are  judged  to  be  of  particular  interest  or  importance  to  computer 
resources  aspects  of  electronic  systems. 
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Section  1,  SCOPS.  As  shown  in  the  Model  Specification,  the  first  section, 
SCOPE,  starts  on  page  1  of  the  specification. 


Subsection  1.1,  Purpose.  The  material  to  be  included  in  this  subsection  should 
consist  of  a  clear,  concise  abstract  in  one  paragraph  of  the  scope  and  purpose 
of  the  coverage  of  the  specification.  If  desired,  a  concise  statement  of  the 
intended  application  of  the  specification  may  also  be  included. 

Subsection  1.2,  Classifications.  This  subsection  is  included  in  the  event  that 
different  classifications  of  the  space  system  are  to  be  covered  by  the  specifi¬ 
cation.  Because  various  classifications  of  space  vehicles  or  other  items  that 
might  be  identified  in  lower  tier  specifications  are  usually  all  part  of  the 
same  system,  the  "Not  applicable"  entry  shown  in  the  Model  Specif ication  is 
usaually  correct. 

Note  that  there  are  minor  differences  in  1.1  and  1.2  between  Appendix  I 
of  MIL-STD-490  and  the  general  requirements  for  Section  1  given  in  the 
body  of  MIL-STD-490.  The  guidebook  presents  a  reasonable  resolution 
of  the  discrepancies. 


1 .  SCOPE 

1-1  Purpose.  This  specification  sets  forth  the  requirements  for  the 
design,  development,  manufacture,  test,  and  duality  assurance  of  the  (in¬ 
sert  nomenclature)  space  system  hereinafter  referred  to  as  the  system.  The 
requirements  covered  bv  this  specification  are  applicable  to  the  (insert 
nomenclature)  svstem  which  is  a  major  element  of  the  (insert  program  iden¬ 
tification).  These  requirements  shall  be  the  basis  for  the  preparation  of 
more  detailed  requirements  to  be  included  in: 

a.  subsequent  revisions  of  the  system  specification,  and  in  related 
system  documents,  such  as  interface  control  documents  (ICDs); 

b.  specifications  for  the  system  segments  and  for  configuration  items 
(CIs)  at  lower  levels  of  assembly. 

1-2  Cl assif ications ■  (Not  applicable). 


Section  2,  APPLICABLE  DOCUMENTS.  As  shown  in  Section  2  of  the  Model  Specifica¬ 
tion,  Governmentai  documents  are  listed  in  subsection  2.1  in  numerical  order 
under  each  of  the  subheadings  shown.  Non-governmental  documents  are  listed  in 
subsection  2.2.  Non-governmental  documents  are  those  not  issued  bv  anv  govern¬ 
mental  organization  such  as  documents  issued  bv  technical  associations,  tech¬ 
nical  societies,  commercial  organizations,  and  contractors. 

The  words,  subhead i ngs ,  and  format  should  be  followed  with  the  understanding 
that  subheadings  will  be  omitted  if  thev  do  not  contain  applicable  documents. 

A  parenthetical  source  statement  should  follow  each  group  of  related 


publication-:  indicating  the  address  of  the  source  of  the  document  so  that 
copies  tnav  be  obtained  directlv  from  the  source. 

All  and  only  those  documents  identified  and  referred  to  in  Sections  3,  4,  and 
5  of  the  specification,  or  in  mandatory  compliance  appendices,  are  listed  in 
Section  2  of  the  specification.  It  must  be  understood  that  the  whole  of 
referenced  documents  is  not  made  applicable  bv  their  inclusion  in  Section  2, 

The  extent  of  applicabi 1 itv  is  only  that  which  is  clear Iv  defined,  and  speci¬ 
fically  indicated,  at  the  Diace  it  is  referenced.  The  documents  listed  in 
Section  2  of  the  Model  Specification  are  those  that  are  alreadv  referenced  in 
the  boilerplate  reauirements  of  the  Model  Specification.  As  other  requirements 
are  added  during  the  preparation  of  a  particular  system  specification,  other 
documents  may  be  referenced  and  they  would  also  be  added  in  Section  2.  Govern¬ 
ment  regulatory  documents,  such  as  directives,  regulations,  manuals,  pamphlets, 
and  policies  are  not  usually  cited  for  compliance.  These  documents  are 
generally  intended  for  internal  use  bv  governmental  organizations  only  and  are 
not  intended  for  contractor  use.  Contractors'  internal  specifications  or 
documents  are  not  usually  cited  for  compliance  because  they  are  tvpically  for 
internal  contractor  use  and  are  not  readily  available  to  reviewing  organiza¬ 
tions  nor  are  they  so  general  as  to  be  directlv  applicable  or  transferable  to 
a  different  contractor. 

Note  that  a  specific  issue,  revision  letter,  and  the  date  of  issue  is  given  for 
each  of  the  referenced  documents.  The  revision  letters,  amendments,  notices, 
and  effective  dates  shown  for  the  documents  listed  in  the  Model  Specif ication 
may  not  be  current;  they  will  require  updating  to  the  date  of  issue  for  each 
specification.  Note  that  amendments  to  military  specifications  supersede 
earlier  amendments  so  only  the  most  recent  would  be  listed.  Notices,  however, 
are  cumulative  and  only  those  notices  to  be  made  applicable  would  be  listed. 

If  all  "m"  notices  were  applicable,  they  would  be  listed  as  notices  "1" 
through  "m"  with  the  date  being  that  for  notice  "m”.  Note  that  the  preferred 
method  of  stating  the  date  of  issue  for  each  document  is  as  the  vear,  month, 
and  day.  The  year  would  be  given  in  two  digits,  the  month  in  three  capital 
letters,  and  the  day  in  two  digits.  If  a  different  date  format  is  used,  it 
should  be  used  consistently  for  all  of  the  documents  listed.  As  the  acquisition 
process  moves  forward,  many  of  the  specific  documents  referenced  may  be  amended, 
revised,  or  superseded.  Just  because  a  referenced  document  may  have  been 
updated  does  not  mean  that  the  revision  should  be  referenced.  The  actual 
updating  of  the  date  of  issue  for  each  of  the  references  in  the  specification, 
however,  must  be  considered  and  controlled  by  the  program  offices  in  the  same 
manner  as  any  other  changes  in  the  specification. 

Note  that  the  preparation  of  this  section  deviates  in  some  areas  from  the 
requirements  in  MIL-STD-483  and  MIL-STD-490.  For  example,  MIL-STD-490 
stares  that  Government  regulations  and  acts  of  Congress  should  be  refer¬ 
enced  in  specifications  whereas  those  "internal"  document  references  are 
nc  lon2et  acceptaole. 


2.  applicable  documents 

2.1  Governmental  documents.  The  following  documents  of  the  exact 
issue  shown  form  a  part  of  this  specification  to  the  extent  specified 
herein . 

SPECIFICATIONS: 

Federal 

Military 

DOD-E-8983C  Electronic  Equipment,  Aerospace,  Extended  Space 
77  DEC  29  Environment,  General  Specification  for 

MIL-M-38310B  Mass  Properties  Control  Requirements  for  Missile 
74  JUN  15  and  Space  Vehicles 

DOD-W-8357A  Wiring  Harness,  Space  Vehicle,  Design  and  Testing, 

77  DEC  22  General  Specification  for 

MIL-S-83576  Solar  Cell  Arrays,  Space  Vehicle,  Design  and 
74  NOV  01  Testing,  General  Specification  for 

DOD-A-83577A  Assemblies,  Moving  Mechanical,  for  Space  Vehicles, 

78  MAR  15  General  Specification  for 

DOD-E-83578  Explosive  Ordnance  for  Space  Vehicles,  General 

79  OCT  01  Specification  for 


Program  Specifications 


(TBS) 


Other  Government  Activity 
STANDARDS: 


Federa 1 


Military 

M1L-STD-1472B  Human  Engineering  Design  Criteria  for  Military 
74  DEC  31  Svstems,  Equipment  and  Facilities 

Notice  1 
76  MAY  10 


Ml I. -STD- 1 522  Standard  General  Keaui rements  for  Safe  Design  and 

72  .Il'l.  ol  Operation  of  Pressurized  Missile  and  Space  Systems 
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DRAWINGS :  CWhere  detailed  drawings  referred  to  in  a  specification  are 

listed  on  an  assemblv  drawing,  it  is  onlv  necessarv  to  list 
the  assemblv  drawing.) 

OTHER  PUBLICATIONS: 

Manuals 

Regulations 

Handbooks 

MIL-HPBK-5C  Metallic,  Materials  and  Elements  for  Aerospace 
Vehicle  Structures 

MIL-HL'EK- 17A  Plastics  for  Flight  Vehicles  -  Part  2,  Transparent 
Glazing  Materials 

Bulletins 


(Copies  of  specifications,  standards,  drawings,  and  publications  required 
by  suppliers  in  connection  with  specified  procurement  functions  should  be 
obtained  from  the  contracting  office  or  as  directed  bv  the  contracting 
officer. ) 

2.2  Non-governmental  documents.  The  following  documents  of  the  exact 
issue  shown  form  a  part  of  this  specification  to  the  extent  specified 
herein . 

SPECIFICATIONS: 

STANDARDS: 

DRAWINGS: 

OTHER  PUBLICATIONS: 

(Technical  societv  and  technical  association  specifications  and  standards 
|  are  generaliv  available  cor  reference  from  librairies.  Thev  are  also  dis- 
1  tributed  among  technical  groups  and  using  Federal  agencies.  The  contract- 
!  ing  officer  should  be  contacted  regarding  the  availabilit-  of  any  refer- 
j  enced  document  not  readilv  available  from  other  sources.) 


Section  3,  REQUIREMENTS.  As  shown  in  Section  3  of  the  Model  Specification,  the 
reauircments  should  be  stated  in  terms  of  performance,  reliabilitv,  design 
constraints,  functional  interfaces,  etc.  that  are  necessarv  to  assure  a 
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practical  .ind  reasonable  development  effort.  The  requirements  shoulc  clear:-, 
describe  the  space  svstem  and  should  include  any  unique  space  requirements  sue': 
as  for  manufacturing  process  control  of  critical  items.  Note  that  the  ma;cr 
elements  of  the  space  svstem  mav  include  ground  equipment  as  well  as  the  space 
eauipment .  Requirements  that  are  onlv  applicable  to  some  of  the  elements  should 
not  he  stated  in  wavs  that  would  make  those  requirements  applicable  to  the 
entire  svstem.  Functional  statements  of  the  reauirements  should  predominate  ir. 
svstem  specifications  with  fabrication  cer^ils  specified  orlv  to  assure  matching 
interfaces  with  existing  elements.  As  the  accuisition  progresses  the  TBSs  and 
Tubs  would  be  determined  and  those  requirements  would  he  incorporated  in  tne 
specification  and,  if  appropriate,  ir.  lower  tier  specif  ic.ations.  The  maicr 
effort  in  the  initial  phases  of  a  program  is  ir  the  allocation  of  the  require¬ 
ments  to  lower  levers  of  assemble’  and  the  preparation  of  specifications  for  the 
svstem  segments  and  lower  tier  Cls. 

Referencing  mil itarv,  federal,  and  I>oD  adopted  industrv  specif icat ions  and 
standards  is  the  approved  method  for  establishing  requirements  that  are  ade- 
ouateiv  set  forth,  ir.  tne  referenced  documents.  Before  referencing  anv  document, 

:>e  sure  to  read  the  specific  issue  of  the  referenced  document  to  assure  the 

appl i  liability  of  the  requirements.  Tailoring  the  references  should  be  accom-  I 

piished  to  limit  the  extent  of  appl icahil it v  of  the  reauirements  suer,  as  illus¬ 
trated  in  the  following  examples: 

a.  "The  design  of  electronic  components  shall  be  in  accordance  with 

DOD-E-8983"  would  incorporate  onlv  the  design  requirements  of  DOD-E- 
3983  for  all  electronic  components  covered  by  the  specif  icat  ie  (both 

ground  anti  spate).  The  qualitv  assurance  provisions  would  not  be  made  ' 

applicable  bv  such  a  reference. 

• .  "The  design  of  the  receiver  X  shall  be  in  accordance  with  POD-E-89S3" 
would  incorporate  nniv  the  design  recuirements  of  DOD-F.-S983  for 
receiver  X,  :ut  no-  for  anv  other  possible  receivers  or  applications 
in  the  svstem  being  specified. 

i 

•■ctror.ie  components  for  space  vehicle  applications  shall  he  in 
'rdance  with  l)Ob-E-3QB3"  makes  all  reauirements  (design  and  qualitv 
assurance)  in  i>'>r>-E-89bj  applicable  to  :  he  electronic  components  to  he 
used  in  .-.pa  <-  venicies  covered  bv  the  specification.  Reauirements  in 
>.b-F.-HOg  Wouid  not  be  made  applicable  to  ground  components  or  to 
aircraft  components  bv  such  a  reference. 

.-  .1  goner, i)  ruit  .  pr  gr.n,  Peculiar  item  spec  it  icat  sons  external  to  the  svster. 

-■  .  .■  spec  i  f  ied  slum  id  n- ■  t  he  referenced  except  to  identifv  an  Interface. 

•*>  id.  :  nf  ar>p i  i can i e  requirements  should  be  extracteo  and  incorporated  in 
1  r  i  re t  ■  . 

1  •  ’  ‘  i  .  jji’ :  ini  t  ion .  The  mien:  <f  the  material  included  in  this  subsec- 

•  untier  parapr  ap;.s  i  ■  r  •  i  ic.iri’  net  me  tne  svstem  that  is  being 
’  As  wile  anv  tic  I"  mi:  ion.  the  ii.ten:  i «  not  to  state  detailed  "shall"  I 

to— ent‘  nut  t.  si:r;  1 -.  uesoriee  tne  s'  t  or  .,nu  ;  identif"  its  tr.a:or  i 

•  eii.e-nt  .  ;  t  s  fun  t  i  ■  1. 1 1  area-  ,  an!  it-  :  u”  •  t  i  on.,  1  ami  -'iivsica  1  I 
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interfaces.  Depending  upon  the  amount  of  svstem  engineering  that  may  have  been 
completed  and  the  complexity  of  the  svstetn  being  specified,  the  definition 
subparagraphs  may  include:  block  diagrams:  functional  diagrams;  logic  diagrams; 
schematic  diagrams;  specification  frees;  pertinent  organizational,  operational, 
and  logistic  concepts;  identification  of  major  svstem  segments;  and  an'  other 
pertinent  descriptive  material. 

These  definition  paragraphs  are  particularly  important  in  a  space  system  speci¬ 
fication.  In  fact,  in  the  initial  draft  of  a  space  svstem  specification,  sub¬ 
section  3.1,  Definition,  may  have  only  text  because  defining  the  svstem  being 
specified  is  alwavs  the  first  step  for  programs  control.  As  the  studies, 
analyses,  and  system  development  progress,  additional  requirements  can  be 
stated.  Eventually  the  subtler  elements  of  the  svstem  can  be  identified  to 
provide  the  framework  of  standard  terminology  to  be  used.  Bv  that  means  all 
oarticipants  can  recognize  common  items,  tasks,  schedules,  costs,  interfaces, 
or  other  common  elements  of  the  system  and  of  the  program.  Although  the 
orimarv  focus  in  these  paragraphs  is  on  the  description  of  the  space  svstem. 
including  its  subtier  elements,  the  svstem  interfaces  with  the  rest  of  the 
world  are  also  to  be  identified.  These  external  interface  descriptions  may 
involve  references  to  other  system  specifications,  or  to  documents  prepared  bv 
other  agencies.  It  is  important  to  recognize  the  "uncontrolled"  nature  of  these 
external  interface  references.  For  example,  a  PoD  space  svstem  specification 
may  describe  an  interface  bv  referencing  ?.  Space  Transportation  Svstem  speci¬ 
fication  issued  by  NASA.  That  reference,  however,  does  not  assure  that  the 
actual  interface  is  as  described  or  that  it  will  not  be  changed  by  NASA  at 
some  later  time. 

In  the  early  phases  of  a  system  acquisition,  the  referencing  of  higher  level 
specifications  or  external  documents  is  the  only  reasonable  course  to  follow  in 
describing  the  interfaces.  As  the  acquisition  progresses,  an  effort  should  be 
made  to  eliminate  these  external  "uncontrolled"  references.  This  can  be 
accomplished  by  the  preparation  and  joint  approval  of  interface  control  docu¬ 
ments.  The  interface  control  documents  could  then  be  referenced  in  the  speci¬ 
fication  or  they  could  be  the  basis  for  the  direct  incorporation  of  the  defir.i- 
tized  interface  requirements.  Eventually,  detailed  configuration  item  (Cl) 
specifications  would  be  prepared  for  the  actual  procurement  of  the  various 
system  elements.  These  Cl  specifications  should  be  "stand  alone"  documents  and 
should  not  reference  higher  level  specifications  or  externally  controlled  docu¬ 
ments.  This  practice  avoids  the  possibility  of  two  documents  each  referencing 
the  other,  and  each  document  stating  that  it  takes  precedence  over  the  other 
document . 

By  including  the  definition  in  the  requirements  section  of  the  specification, 
contractors  and  others  using  the  specification  can  recognize  the  intent  tc 
assure  compliance  with  the  space  system  description  given.  Although  require¬ 
ments  may  include  definitions,  it  should  be  noted  that  definitions  are  not  an 
appropriate  place  to  include  detailed  design  or  test  requirements.  This  sec¬ 
tion  and  the  subparagraphs  are  definitions  that  are  intended  to  be  descriptions 
of  the  svstem  to  be  fulfilled  by  the  detailed  design,  as  opposed  to  statinc 
"shall"  requirements  or  specifying  a  precise  set  of  verifiable  oorformance 
requirements. 


c  1 


•»  •’»  - 


As  shown  in  the  Model  Specification.  3.1,  Svscen  definition,  is  usually  verv 
brie:  with  most  of  the  required  text  entirelv  within  subtier  paragraphs. 

Usually  a  list  of  functional  areas  of  the  svstem  is  included  and  a  list  of 
subtier  elements  of  the  svstem  is  also  included  in  3.1.  These  lists  are  simply 
for  the  convenience  of  those  using  the  specification  and  are  incorporated  into 
the  specification  when  the  information  becomes  available.  For  example,  the 
prime  configuration  items  are  not  usually  identified  precisely  until  after  the 
system  SDecif ication  has  been  fully  completed.  Of  colirse,  the  lists  shown  in 
the  Model  Specification  are  typical  and  should  be  changed  to  conform  to  the 
particular  system  being  specified. 

Paragraph  3.1.1,  General  description,  is  the  paragraph  that  contains  an  expanded 
description  of  the  system  from  that  given  in  3.1  and  identifies  the  functional 
areas  and  the  relationship  of  the  system  being  specified  to  other  systems.  In 
that  context  the  program  should  be  briefly  described  in  terms  such  that  all 
systems  or  other  major  elements  of  the  larger  program  are  identified. 

Paragraph  3.1.2,  Missions,  is  included  to  provide  a  description  of  operational 
missions  and  related  information  that  could  affect  the  design. 

Paragraph  3.1.3,  Threat,  is  included  to  identify  potential  threats  to  the 
system  that  should  be  considered  in  the  design  so  that  the  system  performance 
would  not  be  jeoperdized  even  if  the  threat  conditions  materialized.  For  space 
elements  it  r.ight  include  nuclear  attack,  pellet  attack,  laser  attack,  elec¬ 
tronic  jamming,  all  of  the  above,  cr  none  of  the  above.  For  ground  elements  it 
might  include  conventional  weapons,  sabotage,  nuclear,  or  whatever.  The  Model 
Specification  takes  the  easy  wav  out  and  suggests  (Not  applicable).  Of  course, 
that  may  not  be  the  correct  entry  for  a  specific  system. 

Paragraph  3.1.4,  System  diagrams,  should  incorporate  the  ton  level  functional 
flow  diagrams.  If  a  top  level  functional  flow  diagram  for  the  program  is  devel¬ 
oped  it  should  be  incorporated  into  this  paragraph.  The  program  level  diagram 
provides  the  franework  for  describing  the  system  being  specified,  the  interfaces 
with  other  systems,  and  for  expanding  the  functional  flows  to  lower  levels.  In 
any  case,  the  top-level  functional  flow  diagrams  for  the  system  would  be 
incorporated.  The  system  functional  flow  diagram  should  be  ar.  expansion  of  the 
applicaoie  program  level  functions. 

When  available,  layout  drawings  or  other  graphic  portrayal  which  establish  the 
general  relationship  of  functional  areas  and  the  major  elements  of  the  system 
should  be  included. 

When  the  subtler  elements  of  the  svstem  have  been  identified,  a  specification 
tree  should  also  be  incorporated.  A  specification  tree  is  a  configuration  item 
oriented  diagram  or  chart  that  shows  the  --.llocated  Cls  that  make  up  the  item 
being  specified.  The  specifications  which  identify  each  subitem  would  be  shown 
on  the  tree.  Other  specif ic.ations  which  serve  to  identify  external  interfaces 
including  the  government -con t rac t or  interfaces  may  also  be  shown.  The  specifi¬ 
cation  tree  for  the  entire  program  should  be  included,  if  it  is  available,  to 
assist  in  the  identification  of  the  svstem  interfaces.  in  anv  case,  the  space 
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svstem  specif ication  tree  would  be  incorporated  to  identifv  the  svstem  segments 
and  as  many  of  the  subtier  CIs  as  possible.  This  specification  tree  for  the 
system  does  not  need  to  be  complete,  particularlv  at  the  lower  tier  levels,  but 
the  CIs  that  can  be  identified  will  provide  a  framework  for  correlating  the 
hardware,  the  statement  of  work  tasks,  the  work  breakdown  structure  (WBS) ,  the 
cost  reporting  requirements,  the  program  scheduling,  and  the  data  items  required 
to  properly  manage  the  program.  The  specification  tree,  or  equivalent  inden¬ 
tured  list  of  CIs,  is  needed  by  all  of  the  program  participants  as  early  as 
possible  to  serve  as  a  common  means  of  identification  of  the  program  elements. 

If  the  specification  tree  is  depicted  in  a  separate  document  or  drawing  whose 
size  prevents  incorporation  into  the  specification,  it  is  referenced  by  docu¬ 
ment  or  drawing  number. 


3.  REQUIREMENTS 

3.1  Definition.  The  space  system  is  an  element  of  the  (insert  pro¬ 
gram).  The  system  is  subdivided  into  the  following  system  segments: 

a.  Space  system  segment  which  includes  the  following  identified  con¬ 
figuration  items:  (TBS) 

b.  Ground  terminal  system  segment  which  includes  the  following  con¬ 
figuration  items:  (TBS) 

c.  Data  reduction  svstem  segment  which  includes  the  following  con¬ 
figuration  items:  (TBS) 

3.1.1  General  Description.  (TBS) 

3 . 1 . 2  Missions.  (TBS) 

3.1.3  Threat .  (Not  applicable) 

3.1.4  Svstem  Diagrams. 

3  1.4.1  Functional  Flow  Diagrams.  The  top  functional  flow  diagram 
for  t  ■  system  is  shown  in  Figure  1.  First-level  flow  diagrams  for 
operational,  maintenance,  test,  and  activation  functions  are  shown  in 
Figures  2.  3,  4,  and  5.  (TBS) 

3. 1.4. 2  Specification  Tree.  The  specification  tree  for  this  system 
is  shown  in  Figure  6. 


tZECTRONIC  SYSTEM."  -  COMMENT: 

Samples  of  functional  flow  block  diagrams  reproduced  from  the  system  specifica¬ 
tion  for  a  large  data  processing  svstem  are  provided  in  Appendix  C  of  this 
cm  debook. 
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Paragraph  3.1.5,  Interface  definitions,  may  he  a  heading  (title)  with  subpara¬ 
graphs,  or  text  may  follow  the  title.  The  paragraph  should  identifv  all  func¬ 
tional  and  physical  interfaces  that  must  be  considered;  however,  the  interfaces 
should  not  be  specified  as  precise  inputs,  outputs,  and  dimensions  that  will 
require  inspection  for  verification.  Usually  references  are  made  to  the  func¬ 
tional  diagrams  and  to  the  specification  tree  included  in  3.1.4  to  help  identify 
the  various  interfaces. 

Interface  control  drawings  and  other  engineering  data  may  be  referenced  if 
helpful  to  define  all  functional  and  phvsical  interfaces  required  to  make  the 
svstem  compatible  with  other  items.  Although  the  details  of  the  interfaces 
may  be  stated  in  these  referenced  documents,  the  details  should  be  repeated, 
by  extraction  or  by  reference,  in  the  appropriate  subparagraphs  such  as  in 
3.2,  3.3,  or  3.5  because  paragraph  3.1.5  is  still  part  of  the  definition  sub¬ 
section  . 

At  some  point  in  the  development  of  the  system,  it  will  be  possible  to  identify 
the  interfaces  between  the  subtler  system  segments  that  are  part  of  the  system 
being  specified.  Usually  the  description  of  these  internal  interfaces  would 
reference  the  specification  tree  for  the  space  system  included  in  3.1.4.  As 
with  the  system  external  interfaces,  these  internal  interfaces  are  onlv  defined 
in  this  paragraph  and  must  be  detailed  in  the  3.7  paragraphs  where  the  system 
segment  characteristics  are  stated.  Where  interfaces  may  differ  due  to  changes 
in  operational  mode,  they  shall  be  stated  in  a  manner  which  identifies  specific 
interface  requirements  with  each  different  mode. 


3.1.5  Interface  definitions.  The  space  system  interfaces  with  other 
elements  of  the  space  program  are  defined  in  Figure  7.  (TBS) 

i _ _  ... 


ELECTRONIC  SYSTEMS  -  COMMENT: 

Instructions  in  MIL-STD-490  require  that  this  paragraph  not  only  identify  inter¬ 
faces  (a)  with  other  systems  and  (b)  among  major  parts  of  this  system  but  that 
it  also  provide  (either  directly  or  by  reference)  engineering  data  to  define 
both  functional  and  physical  interfaces  precisely.  This  area  poses  many  prob¬ 
lems  and  potential  pitfalls  for  software,  in  particular: 

a.  Tiie  normal  expectation  based  on  aerospace  vehicle  and  other  hardware  experi¬ 
ence  is  that  many  of  the  physical  interfaces  will  be  defined  late  in  a 
svstem  program  (typically,  "by  CDF."),  then  added  to  this  part  of  the  system 
specification  bv  reference  to  ICDs. 

b.  kith  verv  few  exceptions,  however,  precise  definitions  of  all  interfaces 
affecting  software  should  be  completed  and  available  for  identification 
in  the  system  specification  by  the  end  of  a  validation  phase.  ICDs  are 
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seldom  useful  for  this  purpose  (for  further  discussion  of  considerations 
pertaining  to  software/software  and  software/hardware  interfaces,  see 
ref.  18,  para.  3.41 . 

c.  Interface  information  for  a  large  electronic  system  is  typically  extensive. 
Careful  planning  is  needed  to  avoid  unnecessary  redundancy,  as  well  as  the 
frequent  errors  of  inaccuracy  and  omissions.  "Interfaces"  are  also  perfor¬ 
mance  characteristics  to  be  specified  in  3.2.1,  and  further  amplified  for 
each  system  segment  in  3.7.  Although  inconvenient  to  users,  the  liberal 
use  of  cross-referencing  is  often  preferable  to  repeating  the  same  precise 
definitions  in  multiple  locations. 


Paragraph  3.1.6,  Government  furnished  property  list,  usually  only  consists  of 
a  list  of  the  Government  furnished  property  which  the  system  shall  be  designed 
to  incorporate.  This  list  must  identify  the  property  by  reference  to  its 
nomenclature,  specification  number,  and  item  number  if  available.  If  the  list 
is  extensive,  it  may  be  included  in  an  appendix  or  in  a  separate  specification 
supplement  or  other  document  which  would  then  be  referenced  in  this  paragraph. 
The  list  in  the  Model  Specification  is  typical  and  should  be  changed  to  conform 
to  the  particular  system.  Specific  quantitites,  including  spares,  should  be 
indicated.  If  there  is  Government  property  that  is  essential  to  the  system 
development  that  can  be  loaned  for  that  purpose,  it  should  be  listed  separatelv 
in  this  paragraph.  Government  property  which  can  be  made  available  to  support 
the  system  and  can  be  loaned  to  the  contractor  might  include  computers,  soft¬ 
ware,  tools,  and  trailers.  Often  the  correct  entry  under  the  "For  loan" 
heading  is  (Not  applicable) .  The  schedule  of  availability  and  associated 
costs,  if  any,  for  the  use  of  Government-loaned  propertv  should  not  be  stated 
in  the  specification. 
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3.1.6  Government  furnished  property  list. 

3. 1.6.1  For  incorporation.  The  following  GFP  shall  be  incorporated 
into  the  system  as  indicated: 

a.  COMSEC  equipment  (TBS) 

b.  Rocket  motors  (TBS) 

c.  Explosive  ordnance  (TBS) 

d.  Payload  equipment  (TBS) 

e.  Propellants  (TBS) 

3. 1.6. 2  For  loan.  The  following  Government  property  mav  be  loaned 

for  use  in  developing  the  system:  (TBS) 


85 


Paragraph  3.1.7,  Operational  and  organizational  concepts,  is  usually  included 
in  a  system  specification  to  provide  operational  information  that  could  help 
define  the  system  and  that  could  affect  the  design  such  as: 

a.  The  basic  performance  parameters  upon  which  the  using  activities 
can  base  tactics  which  utilize  the  capabilities  of  the  system  and 
which  should  be  recognized  in  the  design. 

b.  Description  of  the  mission  in  terms  of  relationships  to  other  items 
of  the  system  or  to  other  systems. 

c.  Anticipated  deployment  of  the  system  equipments,  both  geographically 
and  organizationally,  such  as  the  number  of  operational  vehicles, 
number  of  ground  support  installations  and  their  operating  locations. 

Note  that  the  Model  Specification  provides  general  words  for  a  space  system 
where  the  space  vehicle  is  launched  using  either  the  Space  Transportation 
System  (STS)  or  is  launched  using  an  expandable  launch  vehicle.  The  require¬ 
ments  should  of  course  be  worded  to  reflect  the  actual  operational  concept. 

In  addition,  any  organizational  concepts  that  could  affect  the  design  should 
be  included  in  added  paragraphs. 


3.1.7  Operational  and  organizational  concepts.  The  system  supports  a 
space  vehicle  launch  and  possible  retrieval  using  the  Space  Transportation 
System  (STS)  or  for  launch  using  the  (TBS)  expandable  launch  vehicle. 
On-orbit  operations  are  planned  to  be  controlled  from  the  mission  control 
center  (MCC)  located  (TBS)  and  remote  tracking  stations  (TBS). 

3. 1.7.1  STS  operational  concept.  The  following  STS  operational  con¬ 
cept  is  supplied  as  a  guide  for  use  in  the  system  design  and  for  the 
preparation  of  operational  plans  and  test  plans: 

3. 1.7. 1.1  STS  prelaunch.  The  space  vehicle  would  be  transported  from 
storage  or  directly  to  the  launch  base  where  final  space  vehicle  prepara¬ 
tions  and  checkout  would  be  accomplished  at  the  Payload  Preparation  Room 
of  the  STS  launch  facility.  Final  intersegment  and  launch  verification 
tests  would  be  accomplished  after  space  vehicle  and  associated  equipment 
installation  in  the  STS  and  prior  to  launch. 

3. 1.7. 1.2  STS  launch.  During  STS  ascent  to  the  parking  orbit,  various 
space  vehicle  subsystems  or  system  equipments  may  be  powered  on  or  turned 
off  in  order  to  provide  protection  from  the  STS  environments  or  to  comply 
with  STS  safety  requirements.  Space  vehicle  telemetry  to  monitor  vehicle 
status  would  be  provided  to  the  STS  for  monitoring  and  retransmission  (in 
real  time  or  playback)  to  the  ground  monitoring  stations. 

3. 1.7. 1.3  STS  parking  orbit  operations.  While  the  space  vehicle  is 
attached  to  the  STS,  vehicle  telemetry  to  monitor  vehicle  status  continues 
to  be  provided  to  the  STS  for  monitoring  and  retransmission  (in  real  time 
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or  playback)  to  the  ground.  When  the  space  vehicle  is  released  from  the 
STS,  responsibility  for  monitoring  and  control  would  be  transferred  to  the 
ground  mission  control  center  (MCC) .  The  STS  may  provide  assistance  for 
th0  resolution  of  anomalies  when  requested  by  the  MCC.  In  the  event  of 
unsatisfactory  deployment  or  unsatisfactory  space  vehicle  checkout,  the  STS 
would  retrieve  the  vehicle  and  return  to  the  launch  site. 

3. 1.7. 1.4  Space  vehicle  orbit  injection.  After  release  by  the  STS  and 
successful  vehicle  checkout  and  appendage  deployment,  the  vehicle  would 
boost  itself  (or  would  be  boosted)  into  its  operational  orbit  under  command 
from  the  ground. 

3. 1.7. 2  Expendable  launch  vehicle  operational  concept.  When  the  use  of 
an  expendable  launch  vehicle  is  planned,  the  following  operational  concept 
is  the  guide  for  use  in  the  system  design  and  for  the  preparation  of  opera¬ 
tional  plans  and  test  plans:  (TBS) 

3. 1.7. 2.1  Prelaunch.  The  space  vehicle  would  be  transported  from 
storage  or  directiv  to  the  launch  base  where  final  vehicle  preparations  and 
checkout  would  be  accomplished  on  the  launch  vehicle  after  mating.  Final 
intersegment  and  launch  system  verification  tests  are  accomplished  prior  to 
launch. 

3. 1.7. 2. 2  Launch  and  injection.  During  launch  and  injection  to  the 
operational  orbit,  the  various  vehicle  subsystems  may  be  powered  on  or 
turned  off  in  order  to  provide  protection  from  the  launch  and  injection 
environments  or  to  comply  with  other  specified  requirements.  Space  vehicle 
telemetrv  to  monitor  vehicle  status  would  be  provided  during  launch  and 


3. 7. 3. 3  Mission  completion.  At  the  completion  of  the  space  vehicle 
mission,  the  space  vehicle  would  be  either  deboosted  to  the  STS  retrieval 
orbit,  de-orbited,  or  all  equipment  would  be  commanded  off.  For  STS  re¬ 
trieval,  the  space  vehicle  provides  space  vehicle  safety  status  and  other 
required  verification  data  to  the  STS.  Once  captured,  the  space  vehicle 
would  be  stored  in  the  STS  payload  bay.  In  the  event  of  an  unsuccessful  STS 
retrieval,  the  space  vehicle  would  be  de-orbited.  At  the  appropriate  point 
in  the  orbit  the  STS  would  de-orbit  and  return  to  VAFB.  After  STS  rollout 
and  safing,  the  STS  would  be  brought  to  the  STS  Processing  Facility  where 
the  space  vehicle  would  be  removed  and  processed  for  transportation  to  the 
factory.  Also,  in  the  event  of  an  aborted  STS  launch,  it  would  be  at  this 
point  that  the  space  vehicle  would  be  recycled  back  to  the  launch  pad  or  to 
the  factory.  (Where  mission  completion  consists  of  command  all  equipment 
off,  that  should  be  specified  instead  of  retrieval  or  de-orbit.  Where  it 
is  planned  that  a  space  vehicle  launched  using  an  expendable  launch  vehicle 
mav  be  retrieved  or  serviced  using  the  STS,  specific  on-orbit  or  mission 
completion  requirements  would  be  described.) 


Subsection  3.2,  Characteristics.  This  subsection  generally  starts  with  a  title 
heading  for  the  paragraphs  that  follow.  The  intent  of  the  material  included  in 
this  subsection  is  to  clearly  state  in  quantitative  terms  the  pertinent  t>er- 
formance  requirements  and  physical  characteristics  of  the  system.  Requirements 
that  are  applicable  to  a  system  segment  or  to  a  single  prime  Cl,  such  as  the 
space  vehicle,  should  be  stated  in  the  appropriate  paragraph  in  subsection  3.7 
and  not  in  this  subsection. 

Paragraph  3.2.1,  Performance  characteristics,  includes  general  and  detail 
requirements,  under  appropriate  subheadings,  for  all  performance  requirements, 
i.e..  what  is  expected  of  the  system  including  both  the  range  of  values  and 
tolerances.  Again  note  that  the  combined  performance  of  the  entire  system,  or 
at  least  that  of  two  or  more  of  the  system  segments,  are  addressed  in  this  para¬ 
graph  and  the  subparagraphs.  The  performance  of  a  single  system  segment  or  of 
an  individual  Cl  would  be  addressed  in  subsection  3.7.  Other  subparagraphs  for 
other  performance  characteristics  may  be  added  in  this  subsection  depending  upon 
the  system.  Other  typical  headings  may  include  deployment,  instrumentation, 
design  commonality,  and  reference  timelines. 

Paragraph  3. 2. 1.1,  Operational  phases  and  modes,  identifies  each  of  the  opera¬ 
tional  phases  and  modes.  Phases  may  include  launch,  on-orbit,  ground  operations, 
reentry,  and  recovery  although  there  may  be  other  phases  that  could  be  appropri¬ 
ate  to  a  particular  system  such  as:  (a)  surveillance,  (b)  threat  evaluation, 

(c)  target  designation  and  acquisition,  (d)  weapon  deployment,  and  (e)  data 
reduction.  Modes  may  include  various  configurations,  power  levels,  or  other 
differences  that  mav  occur  during  one  of  the  phases  that  requires  special  design 
attention. 

Paragraph  3. 2. 1.2,  Dynamic,  states  the  system  dynamic  performance  parameters 
required  for  each  phase  and  mode. 

Paragraph  3. 2. 1.3,  Endurance,  states  the  Quantitative  criteria  covering  endur¬ 
ance  capabilities  of  the  system  required  to  meet  user  needs  under  stipulated 
environmental  and  other  conditions,  including  minimum  total  life  expectancy. 

The  required  mission  duration  and  planned  utilization  rate  in  the  various  modes 
should  be  indicated.  The  endurance  requirements  stated  in  the  Model  Specifica¬ 
tion  are  tvpical  and  should  be  changed  to  the  times  and  reouirements  of  the 
specific  svstero. 


3 . 2  Characteristics. 

3.2.1  Performance. 

3. 2. 1.1  Operational  Times  and  Modes.  (TBS) 

3. 2. 1.2  Dynamic .  (TBS) 

~  •  1  ■  ”*  Endurance .  The  ground  based  elements  of  the  svstem  shall  have 
a  design  service  life  of  20  years.  The  elements  of  the  svstem  associated 
/itn  the  STS  Orbiter  operations  shall  havj  a  design  service  life  of  13 
vears .  The  on-orbit  design  life  of  the  space  vehicle,  as  mav  be  limited  by 
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mechanical  wearout ,  battery  life,  solar  array  life,  or  the  exhaustion  of 
expendables,  shall  be  no  less  than  five  years.  The  design  of  the  space 
vehicle  shall  be  such  that  space  vehicle  storage,  under  controlled  condi¬ 
tions,  may  be  planned  for  as  long  as  four  years.  The  design  service  life 
of  the  space  vehicle  shall  be  ten  years  based  on  the  sum  of  the  allowed 
storage  time,  pre-launch  checkout  time,  launch  and  injection  time,  on-orbit 
time,  recoverv  time,  and  contingency  time.  (TBS) 

I 

3. 2. 1.4  Other.  (TBS) 


ELECTRONIC  SYSTEMS  -  COMMENT 


Note  that  the  perform, ance  requirements  to  be  specified  here  are  those  which  per¬ 
tain  to  the  system  as  a  whole,  or  are  common  to  two  or  more  segments.  These  are 
later  apportioned  to  each  system  segment  (in  subsection  3.7),  normally  by  refer¬ 
ence  to  this  paragraph,  together  with  additional  requirements  peculiar  to  the 
individual  segments.  Jointly,  the  performance  requirements  set  forth  here  and 
in  3."  constitute  the  principal  content  of  the  system  specification  as  a  whole 
as  it  pertains  to  requirements  for  system  software.  These  are  the  requirements 
upon  which  development  (Type  BS)  specifications  for  CPCIs  will  be  based.  The 
information  should  normally  be  extensive,  in  that  it  should  provide  a  definitive 
translation  of  operational,  organizational,  and  support  concepts  described  in 
the  preceding  paragraph  3.1  into  a  complete  set  of  implementing,  data  processing 
operations. 

ill  system  functions  required  to  perform  the  mission  described  previously  in 
paragraph  3.1  are  to  be  identified.  A  subparagraph  should  be  devoted  to  each 
function  which  specifies  required  performance  associated  with  the  function  in 
terms  of  capacities,  loads/volumes  of  data,  reaction  times,  accuracies,  and 
other  relevant  characteristics.  The  proper  "level"  at  which  these  requirements 
should  be  specified  varies  with  the  system  and  particular  function  being  speci¬ 
fied.  Generally,  the  objective  is  to  define  required  system  capabilities 
comprehensively,  but  at  the  same  time  to  avoid  details  which  can  be  amplified 
later  within  the  intended  scope.  As  an  example: 

"Each  intercept  direction  center  shall  be  capable  of  scrambling  intercep¬ 
tors  from  up  to  6  airbases.  ...  Guidance  commands  shall  be  computer¬ 
generated  and  displayed  to  weapons  team  personnel  to  permit  voice  control 
of  manned  interceptors  on  (types  cf  missions,  types  of  interceptors,  num¬ 
ber  of  interceptors  controlled,  frequency  of  computed  commands,  handling 
of  aborted  missions,  etc.)  ...  When  interceptors  follow  the  commands,  the 
following  accuracies  shall  be  achieved  at  least  87)  of  the  time:  The 
difference  between  actual  and  specified  crossing  angle  at  rollout  shall  be 
less  than  15  degrees;  The  intercept  rollout  point  shall  be  within  4.5 
miles  of  the  desired  rollout  point;  ...” 

Such  requirements,  at  the  system  level,  are  adequate  to  dictate  the  scone  and 
nature  of  amplifying  detail  which  will  then  have  to  be  developed  for  documen¬ 
tation  in  the  Tvne  E5  specification  for  a  CPCI.  The  latter  must  "fill  in" 
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extensive  data  to  define,  for  example:  quantitative  flight  characteristics  of 
each  specified  interceptor  type,  together  with  tracking  and  other  essential 
inputs  to  the  command  computations;  mathematical  formulas  (not  algorithms)  for 
the  computations,  including  timing  and  accuracies;  types  of  operating,  alarm, 
and  other  controller  displays,  together  with  detailed  formats  and  contents  as 
a  function  of  operating  mode,  intercept  phase,  and  contingencies. 


Paragraph  3.2.2,  Physical  characteristics,  sets  forth  physical  requirements  in 
the  appropriate  subheadings  that  are  applicable  to  two  or  more  of  the  system 
segments.  Physical  characteristics  include  such  items  as  weight  limits  and 
dimensional  limits  necessary  to  assure  physical  compatibility  v’ith  other  pro¬ 
gram  elements  and  not  determined  by  other  design  and  construction  features  or 
referenced  drawings.  The  paragraphs  may  also  include  considerations  such  as 
tie  down  requirements  for  transportation,  security  criteria,  durability  fac¬ 
tors,  health  and  safety  criteria,  survivability,  and  vulnerability  factors. 

The  physical  characteristic  requirements  of  a  single  system  segment  or  of  indi¬ 
vidual  CIs  would  be  addressed  in  subsection  3.7  of  the  specification.  Addi¬ 
tional  subparagraphs  may  be  provided  depending  on  the  system. 

Paragraph  3. 2. 2.1,  Mass  properties,  states  requirements  for  limiting  and  con¬ 
trolling  the  mass  properties  of  the  system  elements.  Usually  general  require¬ 
ments  are  stated  for  space  elements  such  as  the  space  vehicle,  the  space 
vehicle  support  equipment  for  use  in  the  STS  orbiter,  and  for  the  payload.  In 
addition,  general  mass  property  requirements  for  fixed  and  mobile  ground  equip¬ 
ment  is  usually  stated  to  avoid  excessive  floor  or  road  loading  or  to  allow 
transportability. 

Paragraph  3. 2. 2. 2,  Dimensions,  identifies  the  coordinate  systems  used  in  the 
svstem  and  any  envelope  constraints  imposed  on  the  system. 

Paragraph  3. 2. 2. 3,  Power,  states  the  requirements  both  for  external  electrical 
power  to  be  supplied  to  the  various  elements  of  the  system  and  for  power  to  be 
generated  by  the  various  elements  of  the  system  and  supplied  to  other  items, 
lare  should  be  taken  to  distinguish  between  power  supplied  to,  and  power  being 
supplied  from,  each  of  the  system  items  during  each  of  the  operating  modes. 

Paragraph  3. 3. 3.4,  Durability,  is  a  general  motherhood  requirement  intended  to 
indicate  the  degree  of  ruggedness  required. 

Paragraph  3. 2. 2. 5,  Survivability,  is  where  requirements  would  be  stated  for 
consideration  of  atomic,  chemical,  biological,  radiological,  fire,  and  impact 
vulnerability  and  survivability. 


3.2.2  Physical  characteristics 

3.2.2. 1  Mass  properties.  The  mass  properties  of  the  space  elements 
shall  be  determined  in  accordance  with  MIL-M-383in.  The  weight  of  the 
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space  vehicle  shall  not  exceed  (TBS).  The  weight  of  the  space  elements 
shall  be  controlled  for  the  preservation  of  performance  margins  and  as  a 
control  of  other  mass  properties.  The  recommended  weight  contingency  for 
space  elements  is  as  follows: 

a.  Preliminary  design  -  new  equipment  20  per  cent 

GFE  &  existing  equipment  5  per  cent 

b.  Critical  design  -  new  equipment  10  per  cent 

CFE  &  existing  equipment  3  per  cent 

c.  Final  design  -  new  equipment  5  per  cent 

GFE  f>  existing  equipment  2  per  cent 

The  mass  properties  of  ground  elements  of  the  system  shall  be  consistent 
with  their  intended  application.  The  weight  of  hand  carried  equipment 
shall  not  exceed  10  kilograms  (kg).  The  center  of  gravitv  of  ground  equip¬ 
ment  shall  be  such  that  probable  seismic  activity  will  not  cause  the  equip¬ 
ment  to  upset.  The  weight  of  ground  elements  shall  be  controlled  to  avoid 
excessive  floor  loading  for  fixed  equipment  and  excessive  road  loading  for 
mobile  equipment.  The  weight  of  all  equipment  shall  allow  transportability 
by  truck  and  C-5  aircraft. 

3. 2. 2. 2  Dimensions .  The  coordinate  definitions  and  envelope  con¬ 
straints  for  the  system  shall  be  as  shown  in  Figure  3.  For  the  spaceborne 
elements,  the  envelope  constraints  shall  be  based  upon  the  dynamic  enve¬ 
lopes  encountered  during  factory  assembly,  system  test,  transportation, 
integration  with  the  booster,  launch,  and  other  phases  of  operations. 

3. 2 .2. 3  Power .  The  primary  electrical  power  on  the  space  vehicle 
shall  be  in  accordance  with  MIL- STD-1539 .  The  primary  electrical  power 
supplied  to  the  system  equipment  mounted  in  the  STS  Orbiter  shall  be  (TBS) . 
The  primary  electrical  power  supplied  to  the  ground  based  elements  of  the 
system  shall  be  (TBS). 

3. 2. 2. U  Durability .  The  system  equipment  shall  be  so  designed  and 
constructed  that  no  fixed  part  or  assembly  shall  become  loose,  no  movable 
part  or  assembly  shall  become  undesirably  free  or  sluggish,  and  no  degrada¬ 
tion  shall  be  caused  in  the  performance  beyond  that  specified  for  the 
system  equipment  during  operation  or  after  storage. 


Paragraph  3.2.3,  Reliability,  and  the  subparagraphs  state  requirements  for  the 
reliability  of  the  system  to  perform  within  specified  limits  for  the  service 
life  of  the  system.  Other  subparagraphs  may  be  added  to  cover  areas  other 
than  MTBF  and  redundancy. 

Paragraph  3. 2. 3.1,  Mean  time  between  failures,  is  where  MTBF  reouirements  are 
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stated  for  the  system.  The  "boilerplate"  in  the  Model  Specification  is  typical, 
but  should  be  changed  for  each  program. 

Paragraph  3. 2. 3. 2,  Redundancy,  is  a  typical  general  statement  of  redundancy 
requirements  for  all  elements  of  a  space  system.  Specific  requirements  may  be 
added,  or  changes  to  the  "boilerplate"  may  be  made  based  upon  the  system 
requirements . 

Paragraph  3.2.4,  Maintainability,  specifies  the  quantitative  maintainability 
requirements  in  the  planned  maintenance  and  support  environments.  The  require¬ 
ments  may  include  such  items  as: 

a.  Time  values  for  mean  and  maximum  down  time,  for  mean  times  between 
maintenance  actions,  for  mean  and  maximum  times  to  repair,  for  reaction 
times,  and  for  turnaround  times. 

b.  Rate  values  indicating  frequency  of  preventative  maintenance,  for 
maintenance  man  hours  per  specific  maintenance  action. 

c.  Maintenance  complexity  including  numbers  of  people,  skill  levels,  and 
variety  of  support  equipment. 

d.  Maintenance  action  indices  including  maintenance  costs  per  operating 
hour  and  man  hours  per  overhaul. 

Note  that  contractor  maintenance  is  generally  applicable  to  space  systems  and 
that  the  same  maintainability  requirements  are  not  usually  applicable  to  all 
elements  of  the  svstem. 


3.2.3  Reliability ■  The  reliability  allocations  shall  assure  that  the 
overall  mission  reliability  requirements  are  met  under  the  most  severe 
extremes  of  storage,  transportation,  testing,  and  operations.  To  the  extent 
practicable,  the  system  design  shall  be  such  that  a  failure  in  one  component 
snail  not  propagate  to  other  devices  or  components.  Where  practicable,  the 
space  vehicle  shall  be  capable  of  detecting  malfunctions  while  in  orbit  and 
automatically  initiating  protective  measures  to  avoid  catastrophic  loss  of 
the  space  vehicle. 

3. 2. 3.1  Mean  time  between  failures.  The  mean  time  between  failures 
for  the  elements  of  tiie  system  shall  be  analytically  determined  for  each 
operating  mode.  Piece  part  or  component  failure  rates  obtained  from  actual 
usage  data  shall  be  used  where  available.  Failure  rates  estimated  from 
standard  data  sources  evaluated  at  anticipated  operating  conditions  shall 
tie  used  when  data  under  actual  usage  is  nonexistent  or  inadequate.  The 
svstem  reliability  shall  be  evaluated  in  terms  of  events  and  usage  cycles 
i  that  occur  during  a  tvpical  service  life  cvcle. 
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The  space  vehicle  probability  of  survival  curve  shall  be  represented  bv  its 
equivalent  Weibull  function: 


R(t) 


where  a. 


scale  parameter 
shape  parameter 


The  space  vehicle  probability  of  survival  for  the  nominal  service  life 
shall  be  at  least  0.5  assuming  the  probability  of  launch  success  to  be  at 
least  0.98.  The  space  vehicle  probability  of  survival  shall  include  cor- 
j  sideration  of  anv  potential  failures  in  associated  ground  operations,  such 
I  as  commanding,  that  might  not  be  corrected  in  time  to  avoid  an  impact  on 
i  the  space  vehicle. 

3. 2. 3. 2  Redundancy .  Redundancy  to  eliminate  single  point  failure 
modes  may  be  incorporated  to  meet  the  reliability  requirements ,  unless  the 
addition  of  redundancy  actually  reduces  overall  reliability  due  to  the 
added  complexity.  For  designs  that  switch  redundant  units,  components,  or 
subassemblies  autonomously,  or  by  command,  the  failure  rates  for  the 
switching  circuits,  and  for  the  redundant  equipment  while  in  the  off-line 
mode ,  shall  be  appropriately  included  in  the  reliability  determination. 
Where  practicable,  provisions  shall  be  incorporated  to  verify  the  operation 
of  all  switchable  redundant  paths  without  disassembly. 

3.2.4  Maintainability.  To  the  extent  practicable,  the  spaceborne  ele¬ 
ments  of  the  system  shall  be  designed  so  as  not  to  require  any  scheduled 
maintenance  or  repair  during  their  service  life.  Where  practicable,  the 
design  of  space  elements  shall  incorporate  test  and  telemetry  points  to 
allow  verification  of  functional  performance  and  shall  accommodate  easy 
installation  and  replacement  of  major  subassemblies.  The  ground  based 
elements  shall  be  designed  with  self  test  features.  The  ground  based  ele¬ 
ments  shall  be  designed  using  modular  construction  for  ease  of  maintenance 
to  assure  the  equipment  availability  required  to  achieve  the  specified 
service  life  and  mission  reliability. 


Paragraph  ?.2.5,  Availability,  states  the  availability  requirements  that  may 
include  availability  for  on-orbit  operations,  for  launch  readiness,  and  for 
recovery.  Availability  is  the  degree  to  which  the  system  must  be  in  an  oper¬ 
able  and  commit table  state  at  the  start  of  a  mission  where  the  mission  is 
called  for  at  an  unknown  or  random  point  in  time.  When  the  STS  is  used,  there 
are  limitations  imposed,  particularly  during  the  prelaunch  and  launch  sequence, 
or.  access  or  availability  of  the  syster  space  equipment  for  test  or  mainte¬ 
nance  activities.  When  applicable,  these  limitations  should  be  stated  in  this 
paragraph  because  of  their  possible  impact  on  the  space  equipment  design  and 
or:  tne  design  and  location  requirements  for  ground  support  equipment . 
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Paragraph  3.2.6  System  effectiveness,  is  marked  (Not  applicable)  because  there 
is  not  a  consensus  as  to  what  it  means.  If  there  are  requirements  relating  to 
system  effectiveness  that  are  not  covered  in  other  paragraphs,  they  should  be 
included  in  this  paragraph. 

Paragraph  3.2.7,  Environmental  conditions,  and  the  subparagraphs  provide  for 
statements  of  the  various  environmental  levels  for  the  system  during  the  various 
operating  phases.  If  environmental  levels  are  specified,  they  should  be  the 
design  levels  that  include  the  desired  margins.  Where  various  levels  are  pos¬ 
sible  during  a  phase,  the  environmental  levels  specified  should  be  a  composite 
that  covers  the  maximum  and  minimum  values.  If  the  use  of  composite  values  is 
not  appropriate,  a  further  subdivision  should  be  used  to  make  the  necessary 
distinction  in  design  levels  for  the  various  configurations  or  categories.  If 
the  system  segments  are  different  from  each  other,  the  environmental  conditions 
would  be  addressed  only  in  3.7.  This  paragraph  would  then  state  "(see  3.7)". 

Paragraph  3.2. 7.1,  Launch  environments,  is  intended  to  present  the  design 
environmental  requirements  for  all  system  items  that  undergo  launch.  This  would 
be  specified  as  the  STS  payload  environment  for  STS  launches,  the  launch  envir¬ 
onment  inside  the  nose  fairing  for  an  expendable  booster  if  that  is  appropriate, 
or  it  would  be  a  composite  of  both  launch  modes. 

Paragraph  3. 2. 7. 2,  On-orbit  environments,  states  the  design  environmental 
requirements  for  orbiting  elements  of  the  space  system.  This  could  include 
separation  from  the  STS,  injection,  various  on-orbit  modes,  and  recapture  by 
the  STS  as  may  be  appropriate  for  the  particular  program. 

Paragraph  3. 2. 7. 3,  Ground  environments,  specifies  the  design  environmental 
requirements  for  the  various  elements  of  the  space  system  that  are  intended  for 
ground  installation  and  use.  However,  note  that  the  orbiting  elements  of  the 
space  system  also  have  a  ground  environment  prior  to  launch  and  possibly  after 
return  from  orbit.  If  any  of  the  handling,  transportation,  or  other  ground 
environments  for  any  of  the  orbiting  elements  exceed  the  design  values  specified 
for  launch  or  on-orbit,  then  those  ground  environments  should  be  specified. 
Either  added  environmental  protection  could  then  be  developed  for  ground  opera¬ 
tions  or  the  ground  environments  would  be  considered  in  the  design  of  the 
orbiting  elements. 

Paragraph  3. 2. 7. 4,  Other  environments,  is  intended  to  specify  the  design 
environmental  requirements  for  the  various  elements  of  the  space  system  during 
other  applicable  phases  not  covered  by  launch,  on-orbit,  or  ground,  such  as 
reentrv  or  crash. 


3.2.5  Availability .  (TBS) 

3.2.6  Svstem  effectiveness.  (Not  applicable) 

3.2.7  Environmental  conditions.  To  provide  a  design  factor  of  safety 
or  margin,  the  various  system  CIs  and  their  components  shall  be  designed  to 
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function  during,  or  if  appropriate  following,  exposure  to  environmental 
levels  that  exceed,  by  the  specified  margins,  the  maximum  levels  predicted 
for  all  applicable  operational  modes  during  the  service  life  of  the  Cl s. 
Unless  otherwise  specified,  the  maximum  predicted  environments  for  the 
spaceborne  equipment  shall  be  determined  in  accordance  with  the  definitions 
in  MIL-STD-1540.  Where  practicable,  each  space  component  shall  be  designed 
to  operate  continuously  within  an  ambient  temperature  range  of  at  least  -34 
deg  C  to  +71  deg  C  and  at  ambient  pressures  between  sea  level  and  deep 
space. 

3. 2. 7.1  Launch  environments.  The  space  elements  shall  be  designed  to 
function  within  performance  specifications  after,  or  if  appropriate  during, 
exposure  in  the  launch  configuration  to  environmental  levels  that  exceed 
the  maximum  predicted  launch  environments  by  the  design  factor  of  safety  or 
design  margin . 

3. 2. 7. 2  On-orbit  environment.  The  space  elements  shall  be  designed  to 
function  within  performance  specif ications  following,  or  if  appropriate 
during,  exposure  in  the  on-orbit  configuration  to  environmental  levels  that 
exceed  the  maximum  predicted  on-orbit  environemnts  by  the  design  factor  of 
safety  or  design  margin. 

3. 2. 7. 3  Ground  environments.  These  environments  are  those  associated 
with  all  operations  of  ground  equipment  and  the  operation  on  the  ground  of 
the  space  equipment,  including  storage,  transportation,  and  prelaunch 
operations.  The  system  CIs  shall  be  designed  to  function  within  perfor¬ 
mance  specifications  following,  or  if  appropriate  during,  exposure  in  the 
ground  configuration  to  environmental  levels  that  exceed  the  maximum  pre¬ 
dicted  ground  environments  by  the  design  factor  of  safety  or  design  margin. 


Paragraph  3.2.8,  Nuclear  control  requirements,  states  the  general  boilerplate 
requirements  for  controlling  nuclear  material.  These  requirements  may  include 
component  design,  in-flight  controls,  and  safety-related  requirements. 

Paragraph  3.2.9,  Transportability,  states  the  requirements  for  system  trans¬ 
portability.  Make  sure  the  last  sentence  in  the  boilerplate  is  consistent 
with  the  ground  environmental  provisions  specified  in  3. 2. 7. 3. 

Subsection  3.3,  Design  and  construction.  This  subsection  generally  starts  with 
a  title  heading  for  the  paragraphs  that  follow.  The  intent  of  the  paragraphs 
included  in  this  subsection  is  to  clearly  state  design  and  construction  require 
ments  and  constraints  that  may  be  applicable  to  the  system  as  a  whole  or  to 
more  than  one  system  segment.  Design  or  construction  requirements  that  are 
applicable  to  a  single  system  segment  or  to  a  single  Cl  should  be  stated  in 
3.7,  not  here. 


Paragraph  3.3.1,  Parts,  materials,  and  processes,  and  the  subparagraphs  are 
general  boilerplate  requirements  for  the  system.  Deletions  or  additions  should 
be  made  where  appropriate  to  satisfy  the  requirements  for  a  particular  system. 

If  the  paragraphs  are  not  applicable  they  should  be  so  marked.  Note  that  the 
management  task  of  establishing  a  parts,  materials,  and  processes  control  pro¬ 
gram  is  not  included  in  the  specification,  but  would  be  stated  as  a  task  in  the 
SOW  when  it  is  a  formal  requirement. 

Paragraph  3.3.2,  Electromagnetic  compatibility,  states  the  general  requirements 
for  EMC.  If  there  are  tempest  requirements  imposed  on  the  system  thev  would  be 
stated  also. 

Paragraph  3.3.4,  Workmanship,  states  the  general  workmanship  requirements 
including  the  workmanship  requirements  for  development  models  or  prototypes  to 
be  produced  during  the  system  development. 

Paragraph  3.3.5,  Interchangeability,  specifies  the  requirements  for  the  level  at 
which  components  shall  be  interchangeable  or  replaceable.  Entries  in  this  para¬ 
graph  are  for  the  purpose  of  establishing  a  condition  of  design,  and  are  not  to 
define  the  conditions  of  interchangeability  that  are  required  by  the  assignment 
of  a  part  number. 

Paragraph  3.3.6,  Safety,  states  the  safety  design  requirements  for  avoiding 
hazards  to  personnel  and  equipment.  Safety  related  requirements  applicable  to 
a  single  functional  area  should  not  be  addressed  in  this  paragraph,  but  would 
be  stated  with  the  requirements  for  the  functional  area  (in  3.7).  Note  that  the 
management  task  of  establishing  a  safety  program  based  upon  an  approved  safety 
plan  is  not  included  in  the  specification.  If  the  management  of  a  safety  pro¬ 
gram  is  desired,  it  would  be  stated  as  a  task  in  the  SOW  and  approval  of  the 
safety  plan  would  be  required  by  an  appropriate  entry  on  the  CDRL. 

Paragraph  3.3.7,  Human  performance/human  engineering,  states  general  boilerplate 
requirements  for  accommodating  man-equipment  interactions.  This  paragraph 
should  also  specify  any  special  or  unique  requirements  such  as  any  constraints 
on  allocation  of  functions  to  personnel  and  verbal  communications.  Specific 
areas,  stations,  or  equipment  that  require  concentrated  human  engineering 
attention  to  avoid  critical  human  errors  should  be  identified. 

Paragraph  3.3.8,  Computer  programming,  states  general  requirements  applicable 
to  computer  programs  to  be  developed  as  elements  of  the  system.  These  may 
include  use  of  standard  programming  languages,  objectives  for  modular  design, 
and  other  design  characteristics  considered  essential  to  minimize  program 
errors  or  facilitate  their  later  operational  use  and  support. 


3.3  Design  and  construction 


3.3.1  Parts,  materials,  and  processes.  Unless  otherwise  specified  in 
the  contract,  the  parts,  materials,  and  processes  shall  be  selected  and 
controlled  in  accordance  with  contractor  established  and  documented  proce¬ 
dures  to  satisfy  the  specified  requirements.  The  selection  and  control 
procedures  shall  emphasize  quality  and  reliability  to  meet  the  mission 


requirements  and  to  minimize  total  life  cycle  cost  for  the  system.  An 
additional  objective  in  the  selection  of  parts,  materials,  and  processes 
shall  be  to  maximize  commonality  and  minimize  the  variety  of  parts,  related 
tools,  and  test  equipment  required  to  fabricate,  install,  and  maintain  the 
svstem.  However,  identical  electrical  connectors,  identical  fittings,  or 
other  identical  parts  shall  not  be  used  where  inadvertent  interchange  of 
items  or  connectors  could  cause  possible  malfunction. 

3. 3. 1.1  Structural  materials.  Materials  shall  be  corrosion  resist¬ 
ant,  or  shall  be  suitably  treated  to  resist  corrosion  when  subjected  to  the 
specified  environments.  Structural  properties  of  materials  for  use  in 
space  applications  shall  be  taken  from  MXL-HDBK  5  for  metals  and  from  MIL- 
HDBK-17,  Parts  1  and  2,  for  plastics.  Properties  not  listed  shall  be 
based  upon  material  tests.  (TBS) 

3. 3. 1.2  Finishes .  The  finishes  used  on  system  CIs  and  their  compo¬ 
nents  shall  be  resistant  to  corrosion.  There  shall  be  no  destructive 
corrosion  when  exposed  to  moderately  corrosive  environments  such  as  indus¬ 
trial  environments  or  sea  coast  fog.  Destructive  corrosion  shall  be  con¬ 
strued  as  being  any  type  of  corrosion  which  interferes  with  meeting  the 
specified  performance  of  the  device  or  its  parts. 

3. 3. 1.3  Material  Selection.  Materials  shall  be  selected  that  have 
demonstrated  their  suitability  for  the  intended  application.  Materials 
used  shall  be  resistant  to  fungus.  Use  shall  not  be  made  of  combustible 
materials  or  materials  that  can  generate  toxic  products  of  combustion. 
Protection  of  dissimilar  metal  combinations  shall  be  in  accordance  with 
MIL-STD-889. 

3.3.2  Electromagnetic  radiation.  The  system  shall  be  designed  in 
accordance  with  MIL-STD-1541 .  Tempest  requirements  are  (TBS). 

3.3.3  Nameplates  and  product  marking.  The  system  CIs  and  each  inter¬ 
changeable  subassembly  shall  be  identified  by  a  nameplate.  The  nameplate 
identification  may  be  attached  to,  etched  in,  or  marked  directlv  or.  the 
item.  Metal  stamping  shall  not  be  used.  Nameplates  shall  contain,  as  a 
minimum,  the  following  identifications: 

a.  Item  or  Cl  number 

b.  Serial  number 

c.  Lot  or  contract  number 

d.  Manufacturer 

e.  Nomenclature 

When  size  limitations,  cost,  or  other  considerations  preclude  marking  all 
applicable  information  on  an  item,  the  nameplate  may  simply  provide  a 
reference  key  to  cards  or  documents  where  the  omitted  nameplate  information 
may  be  found. 
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3.3.4  Workmanship .  Equipment  shall  be  manufactured,  processed,  test¬ 
ed,  and  handled  such  that  the  finished  items  are  of  sufficient  quality  to 
ensure  reliable  operation,  safety,  and  service  life.  The  items  shall  be 
free  of  defects  that  would  interfere  with  operational  use,  such  as  exces¬ 
sive  scratches,  nicks,  burrs,  loose  materials,  contamination,  and  corro¬ 
sion. 

3.3.5  Interchangeability ■  The  design  of  ground  equipment  shall 
provide  for  modular  replacement  of  components  to  expedite  maintenance  and 
repair.  The  design  of  space  elements  shall  provide  for  factory  replace¬ 
ment  of  components  and  for  pre-launch  installation  or  replacement  of 
explosive  ordnance  devices,  batteries,  and  major  space  vehicle  components. 

3.3.6  Safety.  The  system  shall  be  designed  to  minimize  safety  hazards 
to  personnel  and  surrounding  equipment  during  installation,  maintenance, 
ground  test,  transportation,  and  operational  use.  The  safety  requirements 
and  procedures  shall  comply  with  all  local,  state,  and  federal  requirements 
as  well  as  Range  Safety  manuals. 

3.3.7  Human  performance/human  engineering.  Newlv  designed  equipment 
shall  be  in  conformance  with  MIL-H-46855  and  MIL-STD-1472 ,  observing 
principles  and  criteria  set  forth  in  AFSC  Design  Handbook  1-3. 

3.3.8  Computer  programming.  Computer  programs  newly  developed  for  this 
program  shall  be  designed  and  structured  in  such  a  way  that  functional 
requirements  and  computer  program  components  may  be  modified,  added,  or 
deleted  without  requiring  extensive  restructuring  and  recoding  of  other 
components.  Programming  languages  shall  be  used  as  specified  in  3.7.x. 

...  (TBS) 


ELECTRONIC  SYSTEMS  -  COMMENT 

Although  the  system  specification  is  primarily  a  performance -oriented  document, 
subsection  5.5  provides  a  place  for  specifying  those  minimum  design/construc- 
tion  requirements  which  are  identified  as  being  essential  to  effective  Air 
Force  use  or  support  of  the  system.  Specification  writers  have  the  obligation 
to  assure  that  such  requirements  are:  necessary,  in  fact;  consistent  with 
estimated  program  schedules  and  costs;  and  also  fully  compatible  with  basic 
performance  requirements  set  forth  in  other  parts  of  the  specification. 

It  happens  that  paragraph  5.5.8  is  the  only  part  oi  a  svstem  specification  for 
which  instructions  contained  in  either  MIl-STP-490  or  M!’.  STD-485  make  explicit 
mention  of  computer  programs.  Possibly  due  to  that  fact,  there  has  been  a 
noticeable  tendency  to  overemphasize  its  importance  both  as  a  part  of  this 
subsection  and  in  relation  to  other  areas  of  system  requirements  (e.g.,  see 
preceding  comment  on  paragraph  3.2.1).  One  svstem  specification  was  issued  in 
1979- -admittedly ,  a  "worst  case"--in  which  3.3.8  alone  occupied  125  of  the 
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page  svace  in  the  entire  specification !  However,  it  is  clear  that  needs  exist 
for  better  guidance  in  this  area  than  has  yet  been  icmnulated  for  general  use. 
Appendix  B  of  this  guidebook  contains  a  sample  of  one  approach  which  has  been 
proposed,  together  with  further  comments  on  associated  questions  and  problems. 


Subsection  3.4,  Documentation.  This  subsection  is  where  general  documentation 
requirements  should  be  specified.  It  should  be  noted  that  no  requirements  for 
the  delivery  of  documents  or  data  may  be  included  in  this  paragraph,  nor  else¬ 
where  in  the  specification.  Data  or  documents  to  be  delivered  for  review  or 
approval  must  be  listed  in  the  CDRL  and  referenced  in  the  contract.  The 
requirements  included  in  this  paragraph  she uld  outline  the  general  plan  for 
engineering  drawings,  specif ications ,  technical  manuals  and  other  types  of 
documentation  required  to  support  design  reviews,  manufacturing,  testing, 
operations,  maintenance,  and  logistic  support. 


3.4  Documentation.  Only  documentation  listed  in  the  Contract  Data 
Requirements  List  (CDRL)  shall  be  formally  delivered  for  review  or 
approval.  It  is  intended,  however,  that  during  the  course  of  the  system 
acquisition  process  appropriate  results  of  trade  studies,  analyses,  and 
development  efforts  will  be  internally  documented  to  support  design  deci¬ 
sions  and  scheduled  technical  reviews.  The  final  system  documentation 
shall  be  such  that  subsequent  production  items  can  be  produced  that  are 
equivalent  in  all  respects  to  those  tested  or  delivered.  This  final  docu¬ 
mentation  shall  also  be  adequate  to  allow  the  rapid  incorporation  of 
changes  when  necessary.  Operational  procedures  manuals  shall  include 
contingency  procedures  to  minimize  the  impact  of  possible  anomalies. 


ELECTRONIC  SYSTEMS  -  COMMENT 

It  is  normally  advisable  to  include  in  this  paragraph  requirements  for  computer 
program,  documentation  which  will  tend  to  enforce  conformance  with  policies  set 
forth  in  APR  800-14.  Examples  of  statements  to  be  considered  are: 

"All  computer  programs  developed  as  a  part  of  this  system  program  shall 
be  specified  in  accordance  with  the  format  and  content  instructions  of 
MIL -STD- 483  (USAF'l ,  Appendix  Vf." 

"Computer  program  specifications,  manuals,  handbooks,  test,  and  version 
description  documents  shall  be  maintained  for  the  life  of  each  CPCI  to 
reflect  all  Class  I  and  Class  II  changes,  and  the  responsible  computer 
program  developer  or  support  activity  shall  issue  periodic  reports  to 
enable  verification  of  their  status,  in  accordance  with  Appendix  VIII  of 
MIL- STD- 483." 

Such  statements  function  as  requirements  to  be  observed,  not  directly  by  con¬ 
tractors,  but  by  Program  Office  personnel  responsible  for  the  preparation  of 
contract  SOKs  and  CDRLs. 
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Subsection  3.5,  Logistics.  This  subsection  states  the  logistic  requirements 
which  constrain  the  system  design.  The  allocation  of  the  program  level  logistic 
requirements  to  the  system  and  to  lower  tier  levels  is  generally  based  on  mini¬ 
mizing  the  program  and  system  life  cycle  costs.  Production  quantitites,  main¬ 
tenance,  and  refurbishment  opportunities  for  space  systems  are  extremely 
limited  when  compared  with  other  military  equipment.  This  factor  usually  dic¬ 
tates  that  the  contractor  be  assigned  responsibilities  for  logistic  support  for 
the  life  of  the  system.  Nevertheless,  there  may  be  requirements  that  should  be 
stated  here  to  assist  the  contractor  in  the  design. 

Paragraph  3.5.1,  Maintenance,  would  typically  address  such  items  as:  (a)  the 
extent  of  maintenance  to  be  accomplished  at  specified  locations  such  as  at  the 
launch  site,  on-orbit,  at  the  landing  site,  at  operating  sites,  at  the  depot  if 
one  is  to  be  used,  or  at  the  factory;  (b)  test,  maintenance,  repair,  and  refur¬ 
bishment  time  lines;  (c)  use  of  multipurpose  test  equipment;  and  (d)  the  use  of 
module  vs.  part  replacement. 

Paragraph  3.5.2,  Supply,  would  address  such  items  as:  (a)  supply  or  resupply 
methods;  (b)  special  storage  requirements  for  parts  or  items;  (c)  introduction 
of  new  parts  or  items  into  the  supply  system;  and  (d)  distribution  and  location 
of  item  stocks. 

Paragraph  3.5.3,  Facilities  and  facility  equipment,  would  address  the  impact,  if 
any,  on  existing  facilities  and  facility  equipment  or  any  requirements  for  new 
facilities  or  ancillary  equipment  to  support  the  system  logistics.  The  facility 
and  facilitv  equipment  requirements  would  eventually  be  transferred  to  separate 
facility  specifications  or  other  appropriate  documents  to  support  their  procure¬ 
ment.  Generally  facility  procurements  and  space  system  equipment  procurements 
are  entirely  separate  contracts. 


3.5  Logistics .  Equipment  designs  shall  be  based  upon  minimizing  the 
system  life  cycle  cost  assuming  the  contractors  provide  the  logistic  sup¬ 
port  for  the  system  for  its  service  life. 

3.5.1  Maintenance .  (TBS) 

3.5.2  Supply.  (TBS) 

3.5.3  Facilities  and  facilitv  equipment.  (TBS) 


ELECTRONIC  SYSTEMS  -  COMMENT 

The  standard  breakdown  of  this  subsection  into  paragraphs  for  maintenance, 
supply,  facilities  and  facility  equipment  does  not  clearly  provide  for  computer 
program  support,  but  that  topic  should  be  covered.  A  recommended  approach  is 
to:  (a)  use  the  three  standard  paragraphs,  as  intended,  for  equipment  and 
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facilities  only;  (b)  add  a  fourth  parapraDh  entitled  "Computer  Program  Support"; 
and  (c)  insert  a  sentence  into  the  basic  paragraph  3.5  calling  attention  to  this 
organization.  Requirements  addressed  in  the  additional  paragraph  f 3 . 5 . 4 i  should 
include  identification  of  the  responsible  support  center  (e.g.,  N'CPC,  Sacra¬ 
mento  ALC,  or  other,  following  the  initial  period  of  contractor  support),  and 
identification  of  support  functions  to  be  provided  at  the  operating  site(s). 

In  formulating  requirements  in  the  context  of  this  topic  (logistics),  specifica¬ 
tion  writers  should  be  aware  that  "maintenance"  is  basically  a  misnomer  for  a 
computer  program  support  activitv,  which  typically  devotes  the  bulk  of  its 
allocated  time  and  effort  to  making  modifications.  Most  of  those  modifications 
may  be  minor  and  relatively  routine;  however,  every  "fix"  to  a  CPCI  is  a  design 
change,  which  implies  that  planning  in  this  area  must  be  closely  linked  with 
planning  for  system/ software  configuration  management  (see  .APR  800-14,  Chapter 
6,  Section  C) . 


Subsection  3.6,  Personnel  and  training.  This  subparagraph  generally  starts  with 
a  title  heading  for  the  paragraphs  that  follow.  For  space  systems,  most 
personnel  and  training  requirements  are  usually  determined  by  the  contractors. 

If  it  is  intended  that  military  personnel  will  operate  or  maintain  the  system 
equipment,  it  is  important  that  the  required  number  of  personnel  at  each  of  the 
available  skill  levels  be  identified.  For  contractor  operation  or  maintenance 
it  would  be  appropriate  to  describe  in  general  terms  the  educational  background, 
experience,  or  other  qualifications  desirable  for  personnel  selected  to  be 
trained  to  operate  and  maintain  the  system.  Care  should  be  taken  to  avoid 
overly  restrictive  personnel  requirements  because  they  can  impose  costly  con¬ 
straints  on  the  equipment  design  and  on  other  areas  of  the  program  such  as 
requirements  for  spares.  The  training  paragraph  could  address  such  requirements 
as: 

a.  The  concept  of  how  training  should  be  accomplished,  e.g.,  school,  unit, 
or  contractor  training. 

b.  The  need  for  simulators,  training  aids,  or  other  training  equipment 
or  devices. 

c.  The  expected  training  time  and  locations  available  for  training 
programs . 

Subsection  3.7,  Functional  area  characteristics.  This  subsection  generally 
starts  with  a  title  heading  for  the  paragraphs  that  follow.  A  paragraph  would 
be  established  to  address  each  of  the  system  segments  of  the  svstem  that  were 
identified  in  3.1  of  the  specification.  The  requirements  in  these  paragraphs 
may  be  stated  by  simply  referencing  the  applicable  system  segment  specifications 
if  they  exist.  For  the  space  system,  the  system  segment  requirements  may  be 
so  extensive  that  it  may  be  desirable  to  simply  prepare  the  space  system  segment 
specification  at  the  same  time  the  space  system  specification  is  prepared.  In 
that  case,  the  space  system  segment  specifications  will  detail  the  system  per¬ 
formance  characteristics,  physical  characteristics,  special  requirements,  and 
interface  characteristics  allocated  to  each  functional  area/system  segment, 
following  the  full  range  of  format/content  conventions  which  apply  to  the  system 
specification  itself. 
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vi/m-Or 


3 . 6  Personnel  and  training. 

3.6.1  Personnel .  (TBS) 

3.6.2  Training.  (TBS) 

3 . 7  Functional  area  characteristics . 

3.7.1  Space  ovstem  segment.  (TBS) 

3.7.2  Ground  terminal  system  segment.  (TBS) 

3.7.3  Data  reduction  system  segment.  (TBS) 


Subsection  3.8,  Precedence.  Paragraphs  in  the  Model  Specification  are  typical 
boilerplate  for  a  system  specification.  They  address  (a)  precedence  as  it 
refers  to  potential  conflicts  with  other,  referenced  documents,  and  (b)  orders 
of  priority  for  requirements  stated  in  the  system  specification: 

Paragraph  3.8.1,  Conflicts,  states  considerations  in  resolving  conflicts  that 
may  occur  with  referenced  documents.  The  general  rule  is  that  requirements 
stated  in  a  given  document  take  precedence  over  conflicting  requirements  of 
referenced  documents.  In  the  case  of  other  system  specifications,  or  documents 
prepared  by  other  agencies,  it  is  especially  important  that  conflicts  be  iden¬ 
tified  and  resolved.  The  purpose  of  boilerplate  words  in  the  Model  Specifica¬ 
tion  is  to  assure  that  conflicts  with  those  other  documents  be  made  known  and 
directed  to  the  Contracting  Officer  for  resolution. 

Paragraph  3.8.2,  Requirements  weighting  factors,  states  the  relative  importance 
of  requirements  stated  within  the  specification,  since  those  may  not  be  equal. 
Relative  weights  might  be  assigned  to  requirements  in  different  areas,  such 
as  interfaces,  performance,  or  physical  characteristics.  The  relative  weight¬ 
ing  of  individual  factors  by  the  manner  in  which  they  are  stated,  although 
common  practice,  should  be  stated  here  if  it  is  used.  The  suggested  four 
levels  may  be  expanded,  reduced,  or  not  used  at  all  in  a  given  specification. 
Note  that  these  factors  are  appropriate  only  during  early  phases  of  a  program; 
they  should  not  appear  in  product  specifications  intended  to  support  a  produc¬ 
tion  contract. 


3 . 8  Precedence . 

3.8.1  Conflicts.  In  the  event  of  conflict  between  the  documents  ref¬ 
erenced  herein  and  the  contents  of  this  specification,  the  contents  of  this 
specification  shall  be  considered  the  superseding  requirements,  except  when 
a  conflict  involves  interface  requirements  external  to  this  system.  In  the 
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event  of  conflicts  involving  external  interfaces,  the  order  of  precedence 
shall  be  as  directed  by  the  Contracting  Officer. 


3.8.2  Requirements  weighting  factors.  Compliance  with  requirements 
stated  within  this  specification  shall  be  governed  by  the  following  factors: 

a.  "Shall"  designates  the  most  important  weighting  level.  Compliance 
with  these  requirements  is  mandatory. 

b.  "Shall,  where  practicable"  permits  alternative  designs,  items  or 
practice  to  be  used  when  the  use  of  the  alternative  is  substanti¬ 
ated  by  documented  technical  trade  studies.  These  trade  studies 
shall  be  made  available  for  review  or  provided  to  the  Government 
in  accordance  with  the  contract  provisions.  Deviations  from  these 
requirements  do  not  require  formal  approval  by  the  Contracting 
Officer . 

c.  "Preferred"  or  "should"  designates  requirements  from  which  devia¬ 
tions  do  not  require  either  documented  technical  substantiation 
nor  Contracting  Officer  approval. 

d.  "May"  requirements  are  stated  as  examples  of  acceptable  designs, 
items,  and  practices.  Unless  required  by  other  contract  provi¬ 
sions,  deviations  from  these  requirements  do  not  require  technical 
substantiation  nor  Contracting  Officer  approval. 


APPENDIX  R.  SAMPLE  PARAGRAPH  5.5.8 


Paragraph  5.5.8  is  a  part  of  the  svstem  specification  which  is  not  men¬ 
tioned  in  MIL -STD- 4 90  but  is  called  out  for  Air  Force  use  in  MIL- STD-4 85  'T'SAF', 
Appendix  III  (para.  30.51.  Its  function  is  to  provide  a  place  in  the  system 
specification  to  specify  reauirements  for  corrrouter  programs  that  are  comparable 
to  the  types  of  design  and  construction  standards  specified  in  other  parts  of 
paragraph  3.5  as  a  whole  for  items  of  svstem  equipment.  It  happens  to  be  a 
part  of  the  system  specification  which  has  received  widespread  attention  and 
emphasis  in  the  past  few'  years;  and  the  resulting  technical  requirements  con¬ 
tained  in  various  system  specifications  have  tended  to  meet  with  almost -equal lv 
widespread  controversy. 

One  sample  of  specification  requirements  for  this  paragraph  which  has  been 
proposed  for  general  use  is  reproduced  below.  It  is  presented  here  as  an  illus¬ 
tration,  not  as  a  recommendation.  The  sample  is  followed,  in  this  appendix,  by 
a  few  additional  comments  pertaining  to  its  merits  and  shortcomings  from  the 
point  of  view  of  acquisition  management  practices. 


This  general  sample  contains  minimum 
essential  requirements  and  is  intended 
to  serve  as  guidance  for  composing  a 
System  "A"  Specification  Section  3.3.8. 

3.3.8  Computer  Programming.  Computer  programs  and  computer  data  bases 
shall  be  considered  as  software.  Software  shall  be  categorized  as  support 
software  or  applications . 

3. 3. 8.1  General  Requirements.  Software  shall  meet  the  following  design, 
language,  and  coding  requirements: 

3. 3. 8. 1.1  Design  Requirements 

3. 3. 8. 1.1.1  Computer  Program  Structure.  The  computer  program  structure 
shall  consist  of  Computer  Program  Configuration  Item(s),  Computer  Program 
Component (s) ,  and  Module (s). 

a.  Computer  Program  Configuration  Item  (CPCI).  A  CPC I  is  the  actual 
computer  program  end  item  in  the  form  of  computer  instructions  stored  on 
machine-readable  media.  A  CPCI  shall  consist  of  one  or  more  computer  pro¬ 
gram  components. 
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b.  Computer  Program  Component  (CPC).  A  CPC  is  a  functionally,  logi¬ 
cally  distinct  part  of  a  CPCI.  A  CPC  is  identified  for  purposes  of  conve¬ 
nience  ir.  specifying  and  developing  a  CPC I  as  an  assembly  of  subordinate 
elements.  A  CPC  consists  of  a  logical  composition  of  one  or  more  subordi¬ 
nate  or  interfacing  modules. 

c.  Module.  A  module  performs  a  complete  logical  process  by  execution 
of  a  set  of  instructions  which  have  clearly  defined  inputs,  processing 
logic,  and  outputs.  A  module  is  the  smallest  set  of  executable  statements 
able  to  be  assembled  or  compiled.  Each  module  shall  conform  to  the  follow¬ 
ing  conventions: 

(1)  A  module  shall  consist  of  a  set  of  instructions  in  a  form 
consistent  with  the  appropriate  language,  OS,  and  computer. 

(2)  A  module  shall  not  exceed  100  lines  of  executable  source 
code.  This  limitation  excludes  comments  and  data  definitions. 

(3)  A  module  shall  have  only  one  entr^-  statement  and  one  exit 

statement . 

3. 3. 8. 1.1. 2  Top  Down  Design  (TDD).  Software  developed  under  this  contract 
snail  be  designed  in  a  top  down  manner.  The  processing  activities  of  the 
svstem  shall  be  identified  and  organized  beginning  with  higher  levels  of 
organization,  expanded  and  broken  out  to  include  a  more  detailed  definition 
of  the  processing  activities  by  identification  of  subordinate  levels.  The 
lowest  level  of  processing  shall  correspond  to  the  module. 

3. 3. 8. 1.1.3  Top  Down  Implementation  (TDI) 

The  project  software  shall  be  implemented  in  a  top  down  manner 
as  defined  herein.  Conceptually,  top  down  implementation  proceeds  from  a 
single  starting  point  while  conventional  implementation  proceeds  from  as 
manv  starting  points  as  programs  in  the  design.  The  single  starting  point 
does  not  imply  that  the  implementation  must  proceed  down  the  hierarchy  in 
oarallel.  Some  branches  intentionally  will  be  developed  earlier  than  other 
branches.  For  example,  user  or  other  external  interfaces  might  be  imple¬ 
mented  before  some  of  the  other  partitions  to  permit  early  demonstration  of 
software  subsystem  capabilities,  partial  software  system  evaluation,  train¬ 
ing,  or  even  incremental  software  system  acceptance.  The  project  software 
shall  be  implemented  in  a  series  of  RELEASES  which  shall  provide  for 
successive  system  capabilities. 

3. 3. 8. 1.2  Programming  Languages.  Software  developed  for  this  svstem  shall 
ne  restricted  to  one  or  more  of  the  following  languages: 

a.  FORTRAN  as  per  ANSI  STD  X  3.10  -  1966 

b.  FORTRAN  as  per  ANSI  STD  X  3.9  -  1978 
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c.  JOVIAL  J3  as  per  MIL  STD  1588 


d.  JOVIAL  J73  as  per  MIL  STD  1589A 

e.  COBOL  as  per  FIPS  PUB  21-1 

f.  IEEE  ATLAS  Spec.  416A-1978 
3. 3. 8. 1.3  Coding  Requirements. 

3. 3. 8. 1.3.1  Commenting  Standards.  Software  developed  under  this  contract 
shall  adhere  to  the  following  commenting  standards: 

3. 3. 8. 1.3. 1.1  Banners.  A  banner  shall  be  a  block  of  comments  which  appears 
once  at  the  beginning  of  each  module.  A  banner  shall  visually  break  the 
project  software  into  units  of  codes  corresponding  to  the  CPCI  decomposition 
(module  level) .  Banners  shall  have  an  identical  format  for  each  module 
within  a  CPC.  The  banner  shall  enclose  the  following  information:  CPCI 
title,  CPIN,  CPC  title,  and  CPC  number.  The  banner  shall  occur  once  in  each 
module  listing,  immediately  preceding  the  header. 

3. 3. 8. 1.3. 1.2  Headers.  Headers  shall  consist  of  a  block  of  consecutive 
comments  arranged  to  facilitate  the  understanding  and  readabilitv  of  each 
module.  This  form  of  block  commenting  shall  be  used  in  lieu  of  individual 
comments  being  scattered  throughout  a  module.  Headers  shall  occur  once  at 
the  beginning  of  each  module  and  shall  conform  to  the  standards  described 
herein.  The  observer  shall  be  able  to  read  the  MODULE-HEADER  and  understand 
the  processing  activities  of  the  module  without  having  to  read  program  code. 
The  minimun required  MODULE-HEADER  comments  are  described  below.  These 
comments  shall  appear  in  the  form  and  in  the  order  illustrated  below: 

MODULE-HEADER  COMMENTS 

MODULE-NAME  -  Followed  by  a  one-line  functional  description. 

ABSTRACT  -  The  ABSTRACT  shall  be  a  set  of  consecutive  comments  which 
describe  the  module's  purpose,  use,  and  processing  activities.  Elaboration 
on  the  technical  aspects  of  the  algorithms  should  be  avoided  where  refer¬ 
ences  to  external  Government  documentation  would  suffice.  The  ABSTRACT 
should  paraphrase  the  activities  of  the  code  in  English  terms.  References 
made  to  external  Government  owned  documentation  shall  be  listed  in  the 
REFERENCES  comment  section. 

REFERENCES  -  NO-1,  TITLE,  DATE  (YY/MM/DD) 

NO-2,  etc. 

INPUTS  -  Variables,  Tables  (local,  system),  files,  and  other  data 
input  sources  shall  be  identified  senarately  as  to  type,  unit  of  measure, 
size,  limits  and  ranges  of  unit  of  measure,  accuracv  or  precision 
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requirements,  frequency  of  arrival. 

OUTPUTS  -  Variables,  Tables  (local,  system),  Files  and  other  data  out¬ 
put  sources  shall  be  identified  in  the  same  manner  as  inputs. 

PROGRAMS  CALLED  -  Names  of  other  programs  called  followed  by  brief 
abstract  of  purpose  and  pre  and  post  conditions  of  each  call. 

LIMITATIONS  -  Description  of  any  constraints  upon  the  execution  of  the 
program.  For  instance,  conditions  which  would  alter  the  logical  operation 
of  the  program  or  cause  the  results  of  the  program's  computations  to  be 
altered . 

MODIFICATIONS  -  NO-1,  MOD  description,  DATE  (YY/MM/DD) 

NO-2,  etc. 

3. 3. 8. 1.3. 1.3  Special  Comments.  Wherever  code  is  particularly  subtle  or 
confusing,  SPECIAL-COMMENTS  shall  precede  the  statement (s)  to  describe  the 
activities  of  the  subject  code.  SPECIAL-COMMENTS  are  provided  only  to  aid 
the  observer  in  reading  program  code  and  are  not  intended  to  replace 
MODULE-HEADER  comments. 

3. 3. 8. 1.3. 2  Structured  Coding.  Computer  programs  coded  for  the  system 
shall  employ  only  the  control  constructs  listed  below.  These  constructs 
shall  be  built  using  logically  equivalent  language  simulations.  Instruc¬ 
tions  in  the  language  used  shall  follow  the  graphic  representations  in 
Figure  1. 

a.  SEQUENCE.  Sequence  of  two  or  more  operations. 

b.  IF-THEN-ELSE .  Conditional  branch  to  one  of  two  mutually  exclusive 
operations  and  continue. 

c.  DO-WHILE.  Operation  repeated  while  a  condition  is  true.  Test  is 
before  operation. 

d.  CASE.  Select  one  of  many  possible  cases. 

3. 3.8.2  Operating  System  (OS)  Requirements.  The  OS  shall  conform  to  the 
following  requirements: 

a.  The  OS  shall  be  a  vendor-supplied,  off-the-shelf  package. 

b.  OS  augmentations  shall  be  allowed  but  shall  be  limited  to  the 
design  of  new  software.  No  augmentations  shall  be  permitted  to  be  embedded 
within  the  vendor  supplied  OS  software. 

c.  For  all  augmentations,  contractor  developed  software  shall  be 
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developed  to  Interface  the  vendor-supplied  OS  for  all  OS  augmentations. 

d.  No  OS  interface  or  augmentation  software  shall  compromise  the 
capability  of  the  OS  vendor  to  provide  maintenance  over  the  life  cycle  of 
the  systems. 

e.  No  instructions  shall  be  executed  that  will  cause  the  computer  to 
halt  processing  pending  an  external  event,  except  by  the  OS.  An  exception 
to  this  restriction  shall  be  permitted  for  augmentations  to  the  OS  where 
the  augmentation  is  designed  as  an  extension  of  the  processing  control  of 
the  OS.  The  exception  is  subject  to  review  and  approval  by  the  Government 

3. 3. 8. 3  Firmware  Requirements.  Computer  programs  and  data  loaded  in  a 
class  of  memory  that  cannot  be  dynamically  modified  by  the  computer  during 
processing  shall  be  considered  firmware.  Requirements  on  firmware  shall  be 
the  same  as  those  on  software.  Use  of  firmware  shall  be  subject  to 
approval  by  the  Government. 

3. 3. 8. 4  Software  Utility  Services.  This  support  software  shall  provide 
the  following  minimum  capabilities: 


a. 

b. 

c . 

d. 

programs 

e . 


Compilation. 

Assembly  which  produces  relocatable  object  code. 

Linking  type  loader. 

Generation,  maintenance,  and  initialization  of  storage  media  for 
and  data. 

Diagnostics  to  support  fault  isolatior. 


f.  Editing  and  debugging  tools. 

3. 3.8.5  Message  Generation.  The  generation  of  error /diagnostic  messages 
shall  make  a  distinction  between  (1)  the  requirements  for  on-line  messages 
to  facilitate  real-time  fault  isolation  required  to  maintain  the  system  in 
operational  status  and  (2)  the  logging  of  fault  messages  onto  svstem  files 
for  the  category  of  faults  which  require  isolation  and  correction  but  can 
be  addressed  off-line  and  do  not  degrade  the  system  performance.  The 
required  processing  time  to  iden  fy  and  generate  an  error/diagnostic 
message  either  for  on-line  or  off-line  isolation  and  correction  shall  not 
degrade  the  operational  requirements  of  the  system. 


a.  Processor  message  and  advisory  formats  shall  not  require  addi¬ 
tional  interpretation  by  the  operator,  such  as  table  lookups  and  references 
to  documentation,  with  the  exception  of  lengthv  diagnorfii.  procedures  to  be 
followed  by  the  operator  following  an  abnormal  condition. 
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b.  No  computer  program  shall  generate  a  message  or  advisory  identical 
to  one  generated  by  the  OS  or  by  another  program. 

c.  Off-line  error  messages  shall  contain  as  a  minimum  the  following 
information: 

(1)  Time  error  was  detected. 

(2)  Textual  description  of  error  condition. 

(3)  Required  operator  action  where  applicable. 

(4)  Contents  of  instruction  register  and  program  counter  at  time 

of  error. 

(5)  Identification  of  triggering  module. 

(6)  Computer  program  or  system  execution  status  following  the 

error . 

On-line  error  messages  shall  contain  as  a  minimum  the  information  in  items 
(1),  (2),  and  (3)  above. 

3. 3. 8. 6  Program  Coding  Conventions.  Software  developed  under  this  contract 
shall  conform  to  required  coding  conventions  stated  below. 

a.  Each  line  of  source  code  shall  contain  no  more  than  one  statement. 

b.  Source  code  shall  be  clearly  and  conspicuously  annotated  to  explain 
all  inputs,  outputs,  branches,  and  other  items  not  implicit  in  the  code 
itself . 

c.  Names  of  operator  commands,  data  entries,  program  components, 
variables,  procedures,  and  other  software  components  shall  be  consistent 
with  those  used  in  system  design. 

d.  Code  shall  be  written  such  that  no  code  is  modified  during 
execution . 

3. 3. 8. 7  Character  Set  Standards.  Character  sets  shall  conform  to  standards 
in  FIPS-1  Standard  Code  for  Information  Interchange,  ANSI-X3 . 4-1968 . 


Note:  Figure  1,  Control  Constructs 
is  maintained  at  ESD/TOIS 
AV/478-2701 
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The  following  comments  represent  opinions  of  this  author,  based  on  con¬ 
siderations  pertaining  tc  the  suitability  of  the  proposed  sample  for  its  intended 
function  as  a  part  of  the  system  specification.  Technical  merits  of  the 
material,  as  such,  are  not  addressed  here,  although  it  should  perhaps  be  noted 
that  various  portions  of  the  content  have  met  with  both  some  agreement  and 
some  disagreement  among  technical  reviewers. 

Overall,  only  some  portions  of  the  requirements  set  forth  in  this  sample 
are  truly  appropriate  to  intended  and  actual  functions  of  paragraph  3.3.8  in 
the  system  specification.  Roughly  half  of  the  material  does  illustrate  a  form 
and  type  of  material  which  is  in  accordance  with  accepted  specification  prac¬ 
tices,  while  the  other  half  appears  to  have  been  formulated  for  other  purooses. 
Further  work  is  needed  to  "separate  the  wheat  from  the  chaff",  and  to  better 
reflect  the  system  acquisition/contracting  implications  of  requirements  stated 
in  a  system  specification.  More  specifically: 

a.  Portions  of  the  material  which  do  constitute  requirements  suitable  for  this 
paragraph  are  those  specifying  characteristics  of  the  computer  program 
design  and  coding -- i. e. ,  as  contained  in  subparagraphs:  3. 3. 8. 1.1. 2,  Top 
Down  Design;  3. 3. 8. 1.2,  Programming  Languages;  and  3. 3. 8. 1.3. 2,  Structured 
Coding.  When  specified  in  3.3.8,  it  must  be  assumed  that  the  requirements 
are  intended  to  apply  to  all  developmental  CPCIs  in  all  system  segments: 
otherwise,  they  should  be  specified  in  paragraph  5.7  or  in  the  Tyoe  B5 
(Part  I)  specifications  for  individual  CPCIs. 

b.  The  sample  as  a  whole  is  at  odds  with  the  significant  principles  that 
design  and  construction  requirements  should  (1)  be  held  to  a  minimum  and 
(2)  make  maximum  use  of  references  to  existing  standards.  Its  extensive 
coverage  and  detail  suggest  that  this  sample  is  written  more  as  a  vehicle 
for  disseminating  a  variety  of  proposed  general  computer  programming 
standards  than  as  a  serious  model  of  content  for  the  system  specification 
as  such.  That  impression  stems  somewhat  from  repeated  appearance  of  the 
phrase,  "...under  this  contract"  (3. 3. 8. 1.1. 2,  3. 3. 8. 1.3.1,  3. 3.8.6)-- 

a  phrase  which  should  be  reserved  for  some  other  type  of  document --as  well 
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as  from  the  questionable  emphasis  devoted  to  requirements  in  such  areas  as 
the  following: 

(1)  Paragraph  5- 3. 8. 1.1. 3,  Top  Down  Implementation  (TDI).  These  are 
requirements  for  contractor  internal  procedures,  not  for  CPCI  design 
and  construction.  As  such,  they  represent  a  level  of  requirements 
which  should  normally  be  avoided  altogether,  in  either  specifications 
or  contract  statements  of  work.  Such  procedures  are  best  left  for 
the  contractor  to  propose  voluntarily,  e.g.,  as  a  part  of  his  computer 
program  development  and/or  quality  assurance  plans. 

(2)  Paragraphs  3. 5. 8. 1.3  through  3. 3. 8. 1.3. 1.3.  These  are  requirements, 
not  for  design  and  construction  as  such,  but  for  contractor-deliverable 
information  about  the  design  and  construction.  Such  requirements  have 
no  function  in  the  system  specification.  They  will  yield  the  desired 
results  only  if  expressed  specifically  in  each  contract,  in  the  CDRL, 
and  properly  coordinated  with  backup  instructions  provided  therein 

for  (a)  delivery  and  content  of  the  CPCI  product  specification  (DI-E- 
3120A)  and  (b)  delivery  of  the  CPCI  itself  (DI-E-30145) . 

C3)  Paragraphs  3. 3. 8. 4  and  5. 3. 8. 5.  These  are  requirements,  again  not  for 
design  and  construction,  but  for  system  functional  capabilities,  which 
should  be  determined  for  each  system  and  spelled  out  elsewhere  in  the 
body  of  the  system  specification- -notably,  in  paragraph  3.2  and  appro¬ 
priate  subparagraphs  under  3.7. 

(4)  Paragraph  3. 3.8.6,  Program  Coding  Conventions.  This  paragraph  seems 
to  consist  of  a  mixture  of  "afterthoughts": 

•  Subparagraph  fb)  is  subject  to  the  comment  (2)  above. 

•  Subparagraph  (cj  is  a  tautology. 

•  Subparagraph  fdl:  The  phrase,  "...such  that  no  code  is  modified 
during  execution"  appears  to  be  loosely  wordedT  a?  written,  it 
covers  coded  data  values  as  well  as  computer  instructions. 
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APPENDIX  C.  SAMPLE  FUNCTIONAL  FLO’/.'  BLOCK  DIAGRAMS 


This  appendix  provides  a  few  examples  of  functional  flow  block  diagrams 
(FFBDs),  illustrating  one  prominent  form  of  system  engineering  documentation 
which  should  normally  be  contained,  or  referenced,  in  paragraph  3.1.4  of  a 
system  specification. 

The  following  figures,  C*1  through  C-6,  are  drawn  from  a  system  segment 
specification  prepared  for  the  Data  Systems  Modernization  (DSM)  Program, 
reference  16.  The  complete  set  of  FFBDs  contained  in  that  source  consisted  of 
116  diagrams  covering  top-level  through  fourth-  (and  in  some  cases,  fifth-) 
levels,  for  twelve  major  functions.  The  samples  reproduced  here  are  selected 
to  illustrate:  (a)  the  one,  top-level  FFBD  for  the  segment;  and  fb)  one  each 
of  the  first-  through  fourth-level  diagrams. 

Figure  C-l  illustrates  specific  logic  notations  used  in  constructing  these 
FFBDs.  General  rules  and  format  for  the  diagrams  are  based  on  instructions 
contained  in  DI-S-5604. 

NOTES: 

a.  Functions  shown  in  parallel  may  interact,  although  interconnecting  lines 
are  not  provided  to  denote  those  interactions. 

b.  These  diagrams  show  only  the  flow  of  functions/subfunctions  required  to 
carry  out  the  system  mission.  Associated  narrative  definitions,  data 
content,  and  performance  requirements  derived  in  the  course  of  generating 
the  FFBDs  are  documented  in  other  sections  and  paragraphs  of  the  system 
specification. 

c.  The  diagrams  reproduced  here  are  selected  to  illustrate  one  vertical 
"thread"  within  the  total  FFBD  hierarchy- - i. e. ,  each  lower-level  diagram 
expands  one  function  shown  in  the  preceding  diagram.  Arrow's  are  added,  in 
these  figures,  to  identify  the  successively- expanded  functions. 
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Figure  C-l.  Logic  Notations. 


Figure  C-2.  Top-Level  Functional  Flow  Flock  Diagram. 
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SUPPORT  INTEGRATED  OPERATIONS  PLANNING  AND  PREPARATION 


PERFORM  MISSION  PLANNING  SUPPORT 
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RECEIVE/FORMAT  COMMAND  PROCESSING  PARAMETERS 
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